The BFD Mach-O back-end I'm working on now appears to be on a fairly usable state. Yesterday, I had completely successful and really encouraging results building ACL2 with BFD to perform the relocation mechanism on Mac OS X. Therefore, I'm planning to move on to BFD definitively now. From this respect, maybe GCL's local BFD tree could be upgraded to the latest revision. I'm also planning to post the binutils mailing list to see if upstream BFD maintainers would be interested in these added functionalities.
Contrarily to what I said in a previous post (reference 1 below), the logic already in place in build_symbol_table_bfd doesn't need to be change in any way. However, I felt the need to insert two extra calls in fasload. These two calls are basically meant to a) craft a branch island section and b) inject it into the object file being loaded. This branch island section contains stubs to allow the routines in charge of saving and restoring the floating point registers to be callable from anywhere. Without this branch island section, fasload()'ing might fail with a relocation overflow error.
The next thing I have on my to-do list is delve deeper into BFD and add more functionalities to the Mach-O back-end. This means that I should be able to see what is actually needed in sfaslbfd_new.c and how this might be done (reference 2 below).
>From this respect, something confuses me, though. To the best of my understanding, bfd_get_relocated_section_contents is the old way to relocate a section, but is also the only solution available to link in object files of different formats. In turn, when using object files of the same format, the preferred way to relocate a section is to call BFD's relocate_section function. This relocate_section function does not require relocation entries to be canonicalized, which means that, to a certain extent, it cannot be used to program at the lowest common denominator of different architectures. While it might be used to handle different ELF flavors in a standardized way, it will certainly not be possible to handle, say, ELF and Mach-O in the same way. But, again, this is just my present thought on it. As I stated yesterday, I didn't know that bfd_get_relocated_section_contents was broken on some newer Linux arches. If such is the case, does it mean that, on such arches, GNU ld cannot link in object files of different formats (since GNU ld in turn relies on BFD) ? Although this question is not directly related to GCL, it will certainly help me understand things.