[fpc-devel] Proposal to adapt search patch under Haiku using a target specific option (-WH).

[Olivier Coursière]

Hi,

Le 01/01/2019 à 18:01, Karoly Balogh (Charlie/SGR) a écrit :
> 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?

Linking without libc is unsupported since day one. It was there in the 
BeOS port. I have keep it so far in case someone would like to make it 
work and maintain it (and i had no motivation to remove it). I don't 
think it has any value under Haiku though, as syscall interface is not 
stable. Because Haiku come from a commercial OS, we have more a 
tradition of stable APIs than a fixed syscall interface.

I have only maintained the libc/libroot part since the beginning of 
Haiku port ten years ago.

> 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.
You are probably more knowledgeable than me in that area. I have done 
mostly what was enough to make fpc work under Haiku. So, the "for 
historic reasons" excuse fit very well here :-)
> 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:
>
> http://charlie.amigaspirit.hu/temp/private/haiku_pascal_sysinit.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
>    Haiku?)

This comment on a Haiku's commit might help you in that area : 
https://git.haiku-os.org/haiku/log/?id=22ca923f71dd2d59d7f314d186801acb50524106&showmsg=1&qt=grep&q=23975

"BeOS R5's glue code incorrectly calls _thread_do_exit_notification() 
when main() returns, while Haiku does that in exit(). Therefore when 
terminating this way the exit hooks were called twice for executables 
built under BeOS R5. This caused e.g. NetPositive or the R5 svn to crash 
on exit (our network code actually uses those hooks). Fixes bug #1742 
<http://dev.haiku-os.org/ticket/1742>."

> - get rid of the unfinished non-libc mess from the Haiku RTL,
Yes, probably
> and when
>    it comes to libc, make it use the generic Un*x stuff where possible.
It should be already the case for the most part.
> - clean up the old linker support
I don't know what you mean here. fpc currently use Haiku's ld under Haiku.
> - move to a "buildrtl" system for easier future maintenance
It is simple enough for me so far at the current rate (a few commits a 
year in the Haiku area). But if it could be easier, shared and 
consistent with other platforms, + 1 !
> - port/fix to 64bit

With the already proposed changes to simplify the initialization part, 
it is probably "just" a matter of :

- declaring the new architecture in the compiler

- adjusting some declarations to 64 bits here and there

- assembling the compiler

- linking it on a 64 bits Haiku to get a bootstrapped compiler

- compiling everything on 64 bits Haiku with this bootstrapped compiler

- Running the tests suite and fix bugs

Olivier

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190102/ba3dbda2/attachment.html>