Re: [Gcl-devel] BFD related issues

[Camm Maguire]

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

Great!

> 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

OK

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

I think ld uses the relocate_section pathway on all platforms.

> directly related to GCL, it will certainly help me understand things.
> 

Take care,

> Aurelien
> 
> (1) http://mail.gnu.org/archive/html/gcl-devel/2003-10/msg00174.html
> (2) 
> http://mail.gnu.org/archive/html/gcl-devel/2003-10/msg00189.html_______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah