This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: -gc-sections for elf32-dlx and possible buglette in elf32-target.h


    Hi all,

  Hmmf.  Implementing gc-sections on elf32-dlx turns out to be quite tricky:

 - The current port uses the generic linker despite being an elf target.
 - The generic linker doesn't do garbage collection.
 - Switching to the ELF linker gets garbage collection going.
 - But the ELF linker doesn't support HOWTOs with special_function
callbacks.
 - You can see what's coming next, can't you?
 - The current DLX port relies heavily on special_function callbacks.

  So as far as I can see, my options are:

1) Extend garbage collection functionality into the generic linker.
2) Get the dlx-specific RELOCATE_SECTION routine to support HOWTO
special_function calls itself.
3) Figure out how to make the generic ELF linker support special_function
calls.
4) Re-implement the current HOWTOs in a way that only relies on standard ELF
linking and doesn't need any special_function calls.

[ I suppose I should also consider:
5) Forget it, give up and go home. ]

  Option 2) seems tricky to me.  special_function calls expect to be passed
pointers to asymbol and arelent structures for a given reloc against a given
symbol, and the ELF backend doesn't use asymbols and arelents.  I think I'd
have to write lots of code to read in the symbols and relocs and generate
those structures, and there would be way too many opportunities for
inconsistency with the ELF backend's data.

  Option 1) might be the neatest and simplest for the DLX port, but might be
rather likely to be considered too destabilising to be accepted as a patch
without major testing.  Option 3) similarly runs the risk of destabilising
existing ELF ports, particularly if any have overloaded the special_function
field under the impression it wouldn't matter because the elf backend
doesn't use special_function.  

  Option 4) seems like a fairly clean solution, but there may yet be more
issues arising from changing the DLX port from the generic linker to the elf
one.  It's also going to be tricky to be sure that any re-implementation of
the HOWTO structs using only the generic ELF backend linker is going to do
*exactly* the same things as the current special_function hooks do.

  All this is by way of explaining why I haven't yet submitted a patch,
despite Daniel and Ian's generous help around the end of last month.  If
anyone can see any alternative approaches that I've missed, or has any ideas
why any of the options I've listed might be easier or more tricky than I've
thought, I'd appreciate the feedback; I'm liable to go with option 1) for
our internal in-house use here, but I'd rather do something that would turn
into a workable patch for the group if possible and practical.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]