Some background :

Haiku currently supports two compilers toolchains with two sets of libraries and ABI for its 32 bits flavor :
 - gcc 2 for BeOS compatibility
 - gcc 4 (or above : currently 7.3) for newer libraries like Qt (and Lazarus).

The default gcc toolchain can be changed using a command line : setarch currently accepting x86_gcc2 or x86.
Once this is done, the only practical difference from Freepascal point of view is that the search patch should be adapted to use the rights libraries according to the context.

A few years ago, i have open the bug 26486
(https://bugs.freepascal.org/view.php?id=26486) with a first proposal that was too hacky to be committed. Since then, i have made another proposition involving a new command line switch to let specifying the set of search paths when targeting gcc4. This alternative proposal got unnoticed since then.

I am currently looking at packaging Lazarus for Haiku and it would simplify the process a lot in our Haikuports system (our equivalent of Ports in FreeBSD).

So here is the proposal :

I propose to add a -WH option that can accept a "gcc4" parameter to specify the alternative option. This is similar to others -W options used to specify the kind of applications on the same platform (like -WA or -WG for Windows).
It would simplify lazarus building under Haiku using a command like that :

make LCL_PLATFORM=qt OPT="-WHgcc4"

Do you think that kind of options could be upstreamed ? If so, i can update the patch to match current sources and maybe use the same option names as setarch to specify the platform.

If not, i can still patch freepascal sources before packaging freepascal for Haiku through our haikuports system. But it would be, in my opinion, less practical on the long term.

Or maybe someone will come up with a better idea to handle that kind of problems ?

What do you think about this proposal ?

To me, the -WH approach looks reasonable. IMO it can be integrated into trunk.

Hi Olivier,

if you want, I can integrate those changes into trunk for you.

Did you already start working on other CPU support for Haiku?

Do you have any compile-farm similar to gcc-farm?

It would be nice to also get regular testsuite results for Haiku OS!

Have a nice new year celebration!

Pierre

PS: I don't remember if you speak French,
but, just in case,
Bonne et heureuse année
else
Happy New Year!

Le 30/12/2018 à 14:58, Olivier Coursière via fpc-devel a écrit :

Hi Pierre,

if you want, I can integrate those changes into trunk for you.

Thank you for the offer but i should have some free time in the next two days. I should already have the change in a 3.0.4 branch. It should be easy to port to trunk i think. A proper patch would be easier to commit.

Did you already start working on other CPU support for Haiku?

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

Here is the current state :
https://www.haiku-os.org/guides/building/port_status/.

Do you have any compile-farm similar to gcc-farm?

Not yet as far as i know. We have machines to build our packages when new recipe arrive, but no tests machines i think.

It would be nice to also get regular testsuite results for Haiku OS!

Indeed... We now have a working virtio driver and vagrant support. Maybe i will experiment on automating something in a virtual machine on my desktop machine as a first step.

Have a nice new year celebration!

Happy new year !

Olivier

PS: I don't remember if you speak French, but, just in case, Bonne et heureuse année

Yes, french is my native language ;-)

Bonne année, bonne santé ! ;-)

Hi,

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.

It also seems to contain some syscall wrappers, and they should be perfectly fine in inline assembly as well, and really shouldn't be in the startup code in the first place, IMO.

And of course a Pascal startup code would ideally "just work" or with minimal changes on another CPU as well.

I have minimal knowledge about BeOS, but I wrote Pascal startup code for some systems (incl. required compiler changes), I might take a look soon, if no one is faster... :)

Cheers,

Hi,

(Not sure if Olivier is on the list, so keep cc:-ing him...)

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:

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?)
- 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

Cheers,

Hi,

I have updated the patch. The exitcode/haltproc handling was incorrect in the previous version.

Completely untested, because see above, but it compiles at least... %)

make cycle of current trunk works with it now, at least on a VirtualBox'd Haiku, using the 3.0.4 release as bootstrap. I did not test the library version of the startup though. Do you have a good testcase for that?

Charlie

Hi,

Le 02/01/2019 à 07:43, Karoly Balogh (Charlie/SGR) a écrit :

Yes, i am on this list ;-)

Thank you. I will test that, but probably not before this week-end !

> Completely untested, because see above, but it compiles at least... %) make cycle of current trunk works with it now, at least on a VirtualBox'd Haiku, using the 3.0.4 release as bootstrap. I did not test the library version of the startup though. Do you have a good testcase for that?

tlib* tests in tests/test should be a good starting point. Current implementation was done mostly to pass those test cases...

Olivier

Hi,

Le 01/01/2019 à 18:01, Karoly Balogh (Charlie/SGR) a écrit :

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 :-)

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

 Hi,

Le 31/12/2018 à 19:16, Olivier Coursière via fpc-devel a écrit :

A new patch is attached to the original bug for review. See https://bugs.freepascal.org/view.php?id=26486.

The new patch is called : WH_Option_r40744.diff
<https://bugs.freepascal.org/file_download.php?file_id=29814&type=bug>.

Olivier

Hi,

Olivier Coursière wrote

> Should linking without libc (as in, libroot) be supported? I have only maintained the libc/libroot part since the beginning of Haiku port ten years ago.

Well, we do have other libc-only ports, like the macOS/Darwin version. It's best to remove it then. That code looks really old anyway, and not made with the current compiler in mind when it comes to asm capabilities for example, so if anyone wants it, probably best to re-add from scratch.

(Which actually leads us to the question of BeOS port, I'm not sure if there's interest to bring it up to speed again in any way.)

Yeah, I was already suspecting something like this, after looking into the libc exit code, thanks. The exit notification stuff can be remove then. (Now that it's in Pascal, it's quite easy! :)

- clean up the old linker support I don't know what you mean here. fpc currently use Haiku's ld under Haiku.

I mean the linker code still aims to support non-libc linking, which is a bit confusing. If no one has worked on it for 10 years and known to be broken, and no benefits to fix it, maybe it's time to remove it. :)

Well, it makes the bulk of the RTL a bit easier to rebuild with Lazarus at least, and a tiny bit faster from the command line, because it only makes one compiler invocation from then on for most of the units. But not all platforms use it, so it's up to the platform's maintainer to decide. :)

Yup, that list sums it up. Also I'm not sure the do_syscall code is still used in Haiku RTL at this point, but if yes, it needs to be adapted to 64bit too. (Or remove if not needed.)

Cheers,

Hi,

It turned out, it wasn't needed. So I made a really quick hack this morning, and now FPC builds for and semi-works on Haiku/x86_64...

Screenshot:
https://twitter.com/chainq/status/1080826380466696192

There seems to be something wrong with the signal setup so strace is used to hide a fatal error... Also file handling doesn't really work now. But even to get to this level in a few hours was nice.

The patch is of course still a bit of a mess, especially the RTL part, but I can commit the "trivial" parts of it to SVN, if you have nothing against it? Like adding the target to the compiler at least. (This question is to Olivier primarily, as he's the Haiku maintainer.)

Cheers,

Hi,

You were faster than me to check this ;-) I was not sure when i fist saw this message.

For signal handling, my bet would be a problem in declarations of types used in the API. A quick check indicate that i have overlooked some architecture specific declarations in signal.inc. Some parts should be in a sighndh.inc in an arch specific directory. It was not a problem until now ;-)
Maybe some shared declarations contains mistakes too. You can double check haiku headers in
/boot/system/develop/headers/posix/arch/x86/signal.h and /boot/system/develop/headers/posix/arch/x86_64/signal.h

Maybe there is a similar problem for file access functions.

I am more the "de facto" maintainer ;-) Any help is welcome ! Committing all "trivial" parts would be nice (including x86_64 specific declarations). x86_64 version for Haiku is almost there : no need to delay the inevitable ;-)

For the rest, i don't know what change are required that would affect 32 bits port but as long as the compiler can still cycle in 32 bits, it might be "good enough". Everything that is x86_64 do not need to be perfect. It is work in progress after all (and was not working at all until your work).

Olivier

Hi,

Only for fun or retro-computing/historical interest, i think.

I still have a computer with BeOS on it but i haven't boot it for a long time. I have in mind to do a last update for a few years but it is low on my priority list. Probably no technical problems there though : the OS as not changed for obvious reasons ;-). Just a matter of free time to cycle the different versions and some compiling fixes. Maybe on a week-end with bad weather...

Olivier

Hi,

Well, indeed this was the case. packed records are not the way to go when interfacing with C code, to say the least, but there were other minor bits as well. As of r40764, the 64bit compiler works. (Well, it can compile a "hello, world!" to a working executable at least, make cycle I haven't tested yet.) Lets hope I did not break 32bit in the process... :]

Maybe there is a similar problem for file access functions.

Yes, the usual problem with BSD/Unix ports, the stat and dirent records were out of alignment for 64bit. Lets hope I managed to fully fix it...

I think I'm going to progress towards moving also the 32bit RTL to the Pascal sysinit/startup functions and making sure make cycle works on both versions. Then lets figure out what to do with that GCC 4 path patch, which I also don't really like TBH... But we'll see. After that it's back to you, probably. :)

Cheers,

Hi Pierre,

Pierre Muller wrote

It would be nice to also get regular testsuite results for Haiku OS!

I have tested VM automation with vagrant and i should be able to automate something to launch and upload the result in one click. And maybe for x86_64 once i have a binary to bootstrap the compiler. I have checked the make uploadrun but i still don't understand what "automatic login with user fpc" really mean. Is there a document that describe the process of setting up that ?

Olivier

Hi Olivier,

Olivier Coursière wrote

> It would be nice to also get regular testsuite results for Haiku OS! I have tested VM automation with vagrant and i should be able to automate something to launch and upload the result in one click. And maybe for x86_64 once i have a binary to bootstrap the compiler.

I have uploaded a native x86_64 Haiku FPC binary, built from svn r40845:

http://charlie.amigaspirit.hu/temp/private/ppcx64-haiku-boot

Make cycle works fine as of current trunk, however "make all" causes a KDL, unless you disable fcl-process usage in fpmake. See this patch:

http://charlie.amigaspirit.hu/temp/private/haiku_fpmkunit_disable_fcl-process.patch

Also see Haiku Trac #14802.

Charlie

Le 11/01/2019 à 21:24, Karoly Balogh (Charlie/SGR) a écrit :

I already managed to generate a snapshot:

ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/x86_64-haiku/fpc-3.3.1.x86_64-haiku.tar.gz

generated yesterday.

Pierre

Hi

Oh, nice! Did you also ran into this x86_64 KDL (kernel entering debugger mode) during packages build, or it's a crosscompiled snapshot?

If we're about to stuck with a given snapshot for a while, can you re-make the snapshot with today's SVN r40485 or later? That has working stacktraces on signals (i.e. SIGSEGV) and working lineinfo (also for i386 which was also broken before, at least it doesn't work in the 3.0.4 release).

Charlie

Hi Pierre,

Le 11/01/2019 à 21:05, Olivier Coursière a écrit :

I should not asked many different questions in the same message : I still not understand what i should do to configure uploadrun to send test results.

Olivier