RE: RFC: Add output_bfd to bfd_link_info

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

> -----Original Message-----
> From: binutils-owner On Behalf Of H. J. Lu
> Sent: 23 April 2004 03:47


> On Thu, Apr 22, 2004 at 10:39:26PM -0400, Ian Lance Taylor wrote:
> > "H. J. Lu" <hjl@lucon.org> writes:
> > 
> > > On Thu, Apr 22, 2004 at 09:22:01PM -0400, Ian Lance Taylor wrote:
> > > > "H. J. Lu" <hjl@lucon.org> writes:
> > > > 
> > > > > > > I find a need to access output_bfd via 
> bfd_link_info. I was wondering
> > > > > > > why it wasn't there to begin with. Any comments?
> > > > > > 
> > > > > > It's not there because it is passed to every 
> function which needs it.
> > > > > > 
> > > > > 
> > > > > We can remove that argument and access it from 
> bfd_link_info instead.
> > > > 
> > > > And requiring the additional memory access is better because....
> > > > 
> > > 
> > > I don't know if we will see a difference since there will 
> be one less
> > > argument to pass around. I will time it.
> > 
> > I shouldn't have brought up the efficiency argument.  It's 
> meaningless
> > in this context.  Sorry.
> > 
> > We should do whatever makes the code most clear.  Obviously, since I
> > wrote the code, I think it is clearer to explicitly pass down the
> > output BFD.  This is particularly so since passing it to
> > bfd_final_link matches what we do for every other BFD function.
> > 
> 
> There are a few places where bfd_link_info is modifed to include
> output_bfd. If output_bfd is in bfd_link_info, it is not needed.
> 
> 
> H.J.


  I've always been a big fan of the
wrap-up-all-your-state-in-one-big-struct-and-pass-it-down-to-every-function-
as-the-first-argument pattern of code design.  It's fairly efficient on any
cpu that supports indexed addressing, it handles threading and reentrancy
issues without even breaking a sweat, and it's very neat and tidy.  It saves
you from the situation where you gradually end up passing more and more and
more arguments to higher-level functions solely so they can pass them down
to lower-level functions.


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