This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]