This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: RFC: More stuff in struct bfd_link_info
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Michael Meissner <meissner at cygnus dot com>
- Cc: <binutils at sources dot redhat dot com>
- Date: Wed, 9 Jan 2002 18:28:10 -0500 (EST)
- Subject: Re: RFC: More stuff in struct bfd_link_info
On Wed, 9 Jan 2002, Michael Meissner wrote:
> On Tue, Jan 08, 2002 at 09:05:47PM -0500, Hans-Peter Nilsson wrote:
> > There's a some target-specific cruft in struct bfd_link_info
> > (for example "int mpc860c0" and "boolean pei386_auto_import")
> > that could go away (or at least not accumulate) if there was
> > just a target-specific PTR member, say "PTR target_data".
> >
> > Also, I'd like to move "boolean relax" from ld.h:args_type to
> > struct bfd_link_info, so bfd functions can see whether
> > relaxation should be done, and perhaps also set it (only) when
> > necessary; for example if some presumably costly relaxation only
> > needs to be done if certain relocs are present.
> >
> > Thoughts?
>
> One historic problem with target-specific PTR members has been when somebody
> wants to write the program file in another format (S-records, ihex, etc.).
> These formats don't have the target-specific PTR members. I tend to advise
> people, link for the standard object file format, and then use objcopy to make
> a S-record afterwards, instead of telling the linker to make S-records
> directly.
I don't think I understand what you mean by that. I do know the
different route taken when linking to something else than the
source object format, but that's not applicable here. For
example, if the target-specific PTR member carries info
important for handling some reloc, that member *would* be used
by target functions, regardless of the output format. (Perhaps
not a good example, but still an example.)
For that matter, you're not right here: struct bfd_link_info
would still have the target-specific PTR member for all object
formats. Perhaps you're mixing it up with the "bfd" struct;
this is the struct bfd_link_info filled in by the linker, not a
field in the "bfd" struct. It's harder in general to add
target-specific fields to the bfd struct; it must be added in
ways specific to the object format which might be what you're
alluding to.
brgds, H-P