This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: RFC/A: Add a bfd hook for defining common symbols
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