Re: Why bfd_section_<op> (*BFD*, sec, ...?)

[Ian Lance Taylor <ian at wasabisystems dot com>]

Andrew Cagney <ac131313@redhat.com> writes:

> > Andrew Cagney <ac131313@redhat.com> writes:
> >
> >> Why do the section operators take a BFD when the SEC already has a BFD
> >> back-pointer?  Vis: bfd_get_section_name et.al.
> > Historical.
> 
> Ah.  Can it go?  GDB appears to drag "bfd" around based on the equally
> historic assumption that these need it :-)

Hmm.  I dunno.  For some functions, like bfd_get_section_name(), it
seems reasonable to not require a bfd argument.

For others, it seems a little bit trickier.  There are some sections
with have no associated BFD, like bfd_abs_section.  There are some
sections which shouldn't really have an associated BFD, but get one
anyhow because it's a little bit simpler, like special sections
created by the ELF backend linker.  For sections like that, it might
make sense to pass a BFD in some cases.  Of course, right now it
doesn't, at least not for the set of macros defined near
bfd_get_section_name().  But for something like
bfd_canonicalize_reloc(), it might be handy to have the BFD available.

I personally wouldn't object to a patch to add new versions of
bfd_get_section_name() and friends which do not require a BFD.  I
think it would be a little extreme even for BFD to change or remove
the existing definitions, although we could certainly mark the
existing ones obsolete and remove them in the future.  (Naturally if
these macros were documented we would want to mark them obsolete in
the documentation, but, needless to say, they are not documented.)

Ian