[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] BFD related issues
Re: [Gcl-devel] BFD related issues
17 Nov 2003 10:19:35 -0500
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Greetings, and thanks for your work on this, Aurelien!
Aurelien Chanudet <address@hidden> writes:
> 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
OK, but I don't feel comfortable doing this in the 2.6.1 branch.
Would a cvs HEAD branch update suffice?
> binutils mailing list to see if upstream BFD maintainers would be
> interested in these added functionalities.
I'm sure they would be most appreciative. Our local bfd tree was only
meant as a staging area for such patches before we could get them
accepted in binutils.
> 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.
If I understand this, this is very cool, and would dispense with the
need for -mlongcall gcc switches on arches where this is needed
(currently only ppc, arm and perhaps mips). When you get a chance,
show me your patch, and perhaps we could put in an #ifdef to call
these routines only on arches where needed? Again, this would be for
CVS head only I'd think.
Are there any advantages to avoiding the -mlong-calls flag?
> 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
I concur with the former, and don't know about the latter. Its too
bad we chose the 'old' way when I had time to put this together, but
them's the cards.
> 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,
Hmmm. Might still be useful, no? Your opinion? The other route is
to dig into the internals of why relocate_section works on platforms
where bfd_get_relocated_section_contents does not, and put in the
patches to fix the latter. Though it is the 'old' way, I think
binutils upstream would still accept such patches. The question is,
which is less work?
> 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
Never tried to link objects of different formats. When does this come
I think ld uses the relocate_section pathway on all platforms.
> directly related to GCL, it will certainly help me understand things.
> (1) http://mail.gnu.org/archive/html/gcl-devel/2003-10/msg00174.html
> Gcl-devel mailing list
Camm Maguire address@hidden
"The earth is but one country, and mankind its citizens." -- Baha'u'llah