ld-tigcc: Add support for importing ELF object files

[n8pjl]

Support importing ELF object files into ld-tigcc and ar-tigcc.

Support is sufficient for most uses of the tool, but gcc4ti-specific
linking extentions aren't supported due to the lack of customized ELF
toolchains.

The linker was not built around ELF support, so some features like
visibility and weak binding aren't supported beyond the default
behavior. Attempts to use those features proceed with a warning.

Debug info is also not handled, as I have never used that feature with
COFF code and am primarily interested in getting code off my hard drive
and letting others use upstream compilers if they're as crazy as me.

[debrouxl]

Thanks for this contribution :)

Which source code examples, and toolchains, did you use to test your changes ?

[n8pjl]

I tested this mostly with basic 2-3 file c programs with a function and/or global variable (data or bss) in each file. I made them on the spot in /tmp so I no longer have any, but they were trivial tests. There was a lot of linking gcc4ti-compiled code wrapping upstream gcc-compiled code.

ar was pretty trivial to test in the same way, as it does the same thing whether there's one or a hundred symbols or files.

None of this is helpful to you, unfortunately.

For large(r) program testing, I ran a modified dhrystone compiled with absolute addressing using GCC 13 (as discussed on #cemetech) four months ago. I also used clang (git), though that uses pcrel addressing by default which ld-tigcc is very picky about. I can't remember if I got that to link or not, but I know that it wouldn't have run as that program triggered a miscompilation. I have the sources for dhrystone to run on TI-68k calcs.

I'm on vacation now (so I have time to finally submit this), but that means that when I destroyed my gcc4ti installation on my laptop and am getting autoconf errors when reinstalling it, I can't test as thoroughly as I wish. I tried to build the asm components of tigcc.a using ELF, but can't do that until I have a broadband connection.

[n8pjl]

I looked over my dhrystone code and it won't work with a standard m68k-elf or m68k-linux gcc compiler, because those compilers have pointers returned in %d0 while gcc4ti (and the patched gcc that I used) return pointers in %a0. You also have to use -fcall-used-d2 when using upstream gcc.

Funnily enough, another entry in my backlog is the patch I wrote to select the return register for pointers at runtime, rather than compile-time.

I attached the source as a tarball (dry_ti.tar.gz). You can probably fix the ABI issues by making strcpy() return uintptr_t in the wrapper, but I can't compile it at the moment so if you don't want to fiddle with the code I'll be able to do it in a week or two. There's also always objdump and using the -dump option with ld-tigcc.

[n8pjl]

Sorry, I forgot about this PR. I'll prepare a set of assembly sources with a variety of relocations that can be tested with both ELF and COFF assemblers.