RFC: More stuff in struct bfd_link_info

RFC: More stuff in struct bfd_link_info

[Hans-Peter Nilsson]

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?

brgds, H-P

Re: RFC: More stuff in struct bfd_link_info

[Nick Clifton]

Hi Hans-Peter,

> 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".

An excellent suggestion!

> 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.

Hmm, I don't see why not.

Cheers
        Nick

Re: RFC: More stuff in struct bfd_link_info

[Michael Meissner]

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.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: RFC: More stuff in struct bfd_link_info

[Hans-Peter Nilsson]

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