This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [RFD] New binutil 'objsplit'
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Dave Korn <dk at artimi dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 21 Apr 2004 13:58:40 -0400 (EDT)
- Subject: Re: [RFD] New binutil 'objsplit'
- References: <NUTMEGpvDtDJd5IghQY0000054d@NUTMEG.CAM.ARTIMI.COM>
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