[fpc-devel] Linux assembler start-up: rtl/linux/*/*.as

[Marco van de Voort]

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.
 
> 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.

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

> 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.

It would be harder to diff against a new decompiled code.
 
> 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.)

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;