Re: RFC/A: Add a bfd hook for defining common symbols

[Richard Sandiford <rdsandiford at googlemail dot com>]

Nick Clifton <nickc@redhat.com> writes:
> Hi Richard,
>> OK, how does this look?  Tested in the same way as before.
>
> Better - thanks.  You still have a mostly useless bfd * parameter, but I 
> guess that there is a theoretical case where it might be needed.

Well, the bfd is used to determine the number of octets per byte,
so we do need access to it somehow.  I suppose the question is
whether we should:

  (a) pass the output bfd only, and drop the unused bfd_link_info
  (b) pass the bfd_link_info, and get the output_bfd from there
  (c) pass both

I don't like (a) because this is definitely a linking function.
If we want a stable interface, we should pass the bfd_link_info
"just in case".

(b) might be the most logical if we were starting from scratch.
However, all current bfd_target-based macros take an explicit
bfd as their first parameter, which they then BFD_SEND to.
I didn't want to be first to break that consistency, and instead
have BFD_SEND (link_info->output_bfd, ...).  And if the macro
has access to the output bfd, it might as well pass it on to
the underlying target function.  I think it's confusing if the
public macro has a different interface from the target function
that implements it.

(This is what we do for most other target linker functions too;
the only exception I can see is bfd_link_just_syms, which only uses
the bfd for the BFD_SEND, and doesn't pass it on to the target function.)

So yeah, I agree (c) isn't an ideal interface.  It just seemed like
it was the most consistent.

Richard