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: [RFD] New binutil 'objsplit'


On Wed, 21 Apr 2004, Dave Korn wrote:
>   As we all know, there are plenty of targets out there that don't implement
> -gc-sections in the linker.

Are there?  Examples?

>  It seems to be particularly the case for small
> embedded CPU targets, which is a shame, because they are the most likely to
> be running with very limited memory resources such that -gc-sections might
> be a real help.

It's really not that hard to implement; I don't see it as the
big problem you portray it to be.

>   However, every port correctly excludes unreferenced archive members from a
> final link.

Not really correct; they're not really "excluded", they're just
not used.  Garbage-collected sections, as a proper example, are
excluded.

>   So it occurs to me to try and leverage this into proper garbage
> collection.

Why not leverage simplicity of garbage collection in the linker
instead of hacking up a new utility?

>   At first I looked at modifying ar to do this, but it didn't seem too easy
> to fit into the structure of ar, and there wasn't a whole lot of useful
> functionality in ar that would help me.  Then I noticed that objcopy has
> options for keeping or removing sections on-the-fly in the course of copying
> the file.  So I decided to use objcopy to separate each of the sections in
> an object file into individual object files, which could then be archived by
> a standard version of ar.

Well, it seems related to creating archives, so I'd say it's
closer to ar than objcopy.  It's a close call.  But I don't see
why it should be a new utility.

> 1)  First and foremost, does anyone think this functionality might be of any
> interest or use to anyone except me?

I guess so.

> 3)  Should it be reintegrated into objcopy, as a new option,

That, or "ar".

> 4)  Or should I integrate it into ar, despite the fact that doing so would
> basically involve large chunks of code duplication from objcopy into ar (all
> the symbol table gc mechanics, frex) with all the grief that implies.  [ Can
> you tell I don't like this idea?! ]

Why the code duplication?  They could use the same object file.
Or do you mean object code duplication rather than source code?

brgds, H-P


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