RE: [RFD] New binutil 'objsplit'

["Dave Korn" <dk at artimi dot com>]

> -----Original Message-----
> From: Hans-Peter Nilsson 
> Sent: 21 April 2004 18:59

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

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

  It depends whether all you need to do is add sweep and mark hook
functions, or whether you have to write a relocate_section routine as well.
In the end, the main reason I did it this way was because it was the
quickest option open to me under time pressure, and it worked.  By the time
you've been working on a linker port for a week or ten days, and it's still
mysteriously omitting random chunks of bytes from the output sections it
generates, you start to look for a quicker approach to solving the problem
that you originally set out to solve.....

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

  No, I mean source code duplication.  When you say that ar and objcopy
could "use the same object file", do you mean that I could factor out the
code from objcopy into a new source file and then add that source file into
the builds for both ar and objcopy?  Yes, of course you're right and that
would be a far better way to do it than to duplicate all that code.  So
maybe I'll build it into ar after all.  It does map nicely to the idea of a
new commandline switch for ar, and it would save having all those
intermediate one-per-section .o files.


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