Is there a good reason why the Linux start-up is implemented with so much assembler code?

There are lots of inexplicable differences between the corresponding files for different architectures, and there are also inexplicable differences between cprt0.as and gprt0.as on some architectures, or between prt0.as and dllprt0.as. When implementing aarch64-linux I spent a lot of time wondering which architecture I should take as a model.

As far as I can tell very little in those files has to be implemented in assembler: perhaps just the initial argument marshalling and initialising the frame pointer. The rest could be done in Pascal, presumably, with the code shared between architectures. It would be a lot easier to maintain that way.

Some questions to answer if one were going to rewrite that stuff in Pascal:

- In which source file would the Pascal code go?

- Would there be four separate Pascal entry points, one for each assembler file? (Each could take arguments: fini, argc, argv, envp.)

- How to do the equivalent of C longjmp in Pascal, used in x86_64/gprt0.as, for example?

Edmund

- Would there be four separate Pascal entry points, one for each assembler file? (Each could take arguments: fini, argc, argv, envp.)

Presumably various symbols undefined in *prt0.o, defined in the C library, would have to be additional arguments. (Or is there another way of doing it?) Currently these are undefined in gprt0.as on aarch64-linux:

U PASCALMAIN
U __libc_start_main
U __monstartup
U _etext
U _mcleanup
U abort
U atexit

Edmund

In our previous episode, Edmund Grimley Evans said:

Is there a good reason why the Linux start-up is implemented with so much assembler code?

It is meant to be as close as possible to decompiled assembler code. Or at least that is what I did for *BSD(compile with a not too high optimization that only eliminates redundant loads but keeps it readable)

Note that Linux i386 and amd64 have attempts at runtime code in freepascal instead of AS (using inline assembler mostly, but it would allow to spin out pascal)

I tried to mimic that in FreeBSD but got stuck on the reliance weak symbols iirc.

dllprt and gprt might not be as up to date as the other two.

It would be harder to diff against a new decompiled code.

Start studying si_* and their includes in i386/ and x86_64.

- How to do the equivalent of C longjmp in Pascal, used in x86_64/gprt0.as, for example?

There are fpc_longjmp and fpc_setjmp symbols but they are related to
exception handling. In an emergency, simply asm jmp $x end;

28.05.2015 10:49, Marco van de Voort пишет:

It is not an emergency case. Libc expects 'main' to return and then executes finalization code. FPC's PASCALMAIN terminates the process and does not return. So in order to get correct library finalization (including profiling with grpof) we have to simulate a return using something like longjmp. It's basically a dirty hack. A much cleaner solution could be to change code generation so it calls FPC_LIB_EXIT instead of FPC_EXIT at the end of PASCALMAIN (so that _haltproc is not called and PASCALMAIN normally returns), and call _haltproc explicitly in code of prt0.as. But whoever goes for that will have to change and test all startup files for all targets, which is pretty time-consuming.

Regards,
Sergei