[fpc-devel] Proposal to adapt search patch under Haiku using a target specific option (-WH).
Karoly Balogh (Charlie/SGR)
charlie at scenergy.dfmk.hu
Tue Jan 1 18:01:25 CET 2019
(Not sure if Olivier is on the list, so keep cc:-ing him...)
On Mon, 31 Dec 2018, Karoly Balogh (Charlie/SGR) wrote:
> > Not really. I have investigated what need to be done for x86-64 port but
> > the assembly part (cprt0.as) was enough to dissuade me so far ;-) Other
> > CPUs will require a working kernel first ;-) Help is welcome though, on
> > both sides...
> At this point it really should be possible to write all/most of the
> startup code in Pascal. I looked into it quickly, and it's actually pretty
> simple, there doesn't seem to be anything really in the i386 startup code
> at least which might be impossible to tackle in a Pascal version.
Ok, so looked into the Haiku port a bit.
Should linking without libc (as in, libroot) be supported? So far, the RTL
seems to depend on linking against libc/libroot, but I'm not sure what was
the intention originally, as there seems to be larger bits of unfinished
direct syscall code as well. Same applies to the linker logic, it seems to
attempt to support linking w/o libc, but looking at the RTL i'm quite sure
that never worked. So for now I'm going to assume it's libc only?
Also, the inline assembly there (and some Googling) seems to suggest that
PIC code is the default on Haiku, while FPC compiled code w/o it (probably
for historic reasons) so for now I enabled PIC and PIC via GOT on Haiku.
Also, anyone with a working set of cross-as/cross-ld/cross-strip from
macOS to Haiku? I tried to build it, and it claimed I need a case
sensitive FS, and I was too lazy to create a separate disk image for that
for now... :)
So, bottom line, see the following patch:
Completely untested, because see above, but it compiles at least... %)
Also, it needs the Makefile regenerated in rtl/haiku, after the applying
the patch. At least the generated code is remarkably similar to the
assembler startup code... So i'm sure it would work with some minor fixes
(symbol names maybe, linking order, etc), worst case.
Some of the possible next steps would be:
- test & fix until it works. :)
- see the legacy comments in si_c.pp and si_dllc.pp and figure out what
to do with those. (Probably only needed to support BeOS, but not
- get rid of the unfinished non-libc mess from the Haiku RTL, and when
it comes to libc, make it use the generic Un*x stuff where possible.
- clean up the old linker support
- move to a "buildrtl" system for easier future maintenance
- port/fix to 64bit
More information about the fpc-devel