> OK, but I don't feel comfortable doing this in the 2.6.1 branch.
> Would a cvs HEAD branch update suffice?
Sure it would suffice. However, if this is too much hassle, let things stay as they are, as it will not deliver significant performance improvement, I guess.
> 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?
That's the point, indeed. My opinion is that there aren't that many advantages to avoiding this flag, compared to the work it would be to add these #ifdef's, though (this would mean going though the reloc chain a first time, determining what relocs would potentially overflow, allocating the right number of stubs, and finally patching the symbol table). This flag defaults to making all function calls via pointers, so that the main disadvantage to using this flag, if any, is that it results in larger object files (for ppc at least).
The reason I added this branch island stub section is that, on Mac OS X, gcc will actually leave some functions to be called directly, not through pointers, despite the use of this flag (or the equivalent -mlong-branch, which is Apple only). My thought is that it might be undesirable to add an extra level of indirection in speed critical calls, which might be why gcc leaves calls to floating pointer register preservation routines as they are, on Mac OS X.
> 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?
Hmmm. Would it be possible for me to have remote access to such an architecture where bfd_get_relocated_section_contents does not work ?
> Never tried to link objects of different formats. When does this come
> up?
Neither have I, and this probably doesn't come up that often. However, this somewhat unique feature caught my attention, which is why I was inquiring about it :-)