#3578 Support for Haiku as an host system

[Adrien Destugues]

Hello,

I am maintaining the packaging of SDCC for Haiku.

My job would be slightly easier if you would integrate the first two changes in this patchset: https://github.com/haikuports/haikuports/blob/master/dev-embedded/sdcc/patches/sdcc-4.2.0.patchset

These are:

• Addition of Haiku in the config.bfd file so that the buildsystem recognizes it as a real operating system
• Some missing includes

The patch also contains other changes that may or may not be relevant:

• Some include path fixes in configure.ac, I am not sure if this is still needed or not (I have been updating this patch from previous versions several times)
• Kevin Thacker's patch for generating binary files with relocation info in a simple format. This was originally developped for the port of the Contiki operating system to the Amstrad CPC. I don't think it is currently used anywhere else. I put it in the Haiku packaging for my own convenience because that's what I use to compile Contiki. But it would make sense for this to be upstream. It has no effect unless the -h option is used with the linker to enable generating the relocation table.
• Removal of "strip" calls in the install targets. This is because the Haiku packaging already takes care of generating a separate package with the debug information, and that won't work if starting from stripped executables. Ideally, you would make the stripping optional with some configure option, but I'm fine with keeping this as a patch
• Change of -ggdb to -gdwarf-3. Likewise, this is Haiku specific (we don't use gdb). I think the simplest solution here is that I keep maintaining this part of the patch on my side.
• Backport of a bugfix from upstream. Obviously you can ignore this one, you already have the fix and I took it from you.

[Philipp Klaus Krause]

The change to config.bfd is in binutils, I think @felixs knows the most about that and should decide.
The missing include is in uCsim, I think @drdani knows the most about that and should decide.

[Felix]

The hunks containing


;;

• x86_64--haiku)
• targ_defvec=x86_64_elf64_vec
• want64=true
• ;;
x86_64--rdos)


and

;;

• i[3-7]86--haiku)
• targ_defvec=i386_elf32_vec
• ;;
i[3-7]86--interix)


look innocuous to me. I suggest to add a comment to those cases, something like "# added for sdcc". (Remember this is a fork, and such changes may be better targeted at the upstream project.)

thanks
felix

[Adrien Destugues]

Thanks for the quick response :)

The binutils changes are already in upstream binutils (in fact, the upstream version contains support for even more Haiku architectures, not all of which actually exist in an usable way yet)

https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/config.bfd;h=78752994456204a3c1184f9bca457f2d966afc29;hb=HEAD

So this is just re-synchronizing the parts I needed from upstream.

[Philipp Klaus Krause]

Has the upstream Haiku support made it into an upstream release?
In that case it might be the easiest to just rebase our fork on that release.

[Adrien Destugues]

The patch was merged in late 2021: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d85e70a35bffa755fd3e9f4ccc6bf6c64953e85d

I think all versions after binutils 2.38 or 2.39 should include it.

[Philipp Klaus Krause]

Our fork is currently based on 2.38, which was released in February 2022. Current upstream binutils is 2.40.

[Adrien Destugues]

Yes, and after checking the current upstream source, I can confirm the Haiku changes are already there: https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/support/sdbinutils/bfd/config.bfd

So, this part is already done and I will just have to wait for the next SDCC release.

[Philipp Klaus Krause]

https://www.z88dk.org/forum/viewtopic.php?t=9645 says there are some issues with Kevin Tacker's relocation. Maybe we should wait on this until we have some kind of consensus among SDCC users on what would be a good way to do this.

[Adrien Destugues]

The limitation (no handling of overflows in split 16-bit relocations) is known (I had forgotten about it, sorry). I think Contiki aligns the loaded executables to 256 bytes so it doesn't hit the problem. Or maybe I was just lucky to not hit it so far?

Anyway, this should probably be discussed in a separate ticket. I will make one when I have Contiki adjusted to the new SDCC calling convention.

[Philipp Klaus Krause]

For -ggdb vs -gdwarf-3 question, would it make sense to just use -g instead? AFAIK -g is supposed to emit the host system's "native" debug information format.

[Adrien Destugues]

That would work for me, but I don't know if you want to force gdb debuginfo on OS where it is not the default.

[Philipp Klaus Krause]

I think we will still want to strip on "make install" by default. After all "make install" isn't just for package maintainers, but for users that compile their sdcc themselves.

[Adrien Destugues]

Yes, it should be the default, but ideally there would be an option to disable it, or a different target to install the files with debug info preserved. There is an "install-strip" target in some of the Makefiles, I expected that install-strip would strip, and install would not. But this is inconsistent accross sdcc buildsystem, some things are stripped in "install" and do not have an "install-strip".

Maybe it is not worth the effort and I can keep this patch on my side. It is simple enough now that I have found what I need to do.