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: incongruency in architecture mismatch linker warnings/errors


On Tue, Jan 21, 2003 at 11:38:32AM -0800, Doug Evans wrote:
> Alan Modra writes:
>  > On Mon, Jan 20, 2003 at 12:09:25PM -0800, Doug Evans wrote:
>  > > It's odd that if the architectures (or mach's) are incompatible during
>  > > a relocatable link it's automatically an error whereas in a final link
>  > > it's only a warning and then only if the user asks for it.
>  > > 
>  > > Is there any reasoning behind this?
>  > 
>  > We might be able to use a "foreign" input file in a final link if the
>  > generic linker support for that particular input is good enough.
>  > For relocatable output, we'd need to translate relocs from one format
>  > to another..
> 
> That's what the comment above the code essentially says.
> Guess I didn't constrain my question enough. :-)

Sorry, I replied without looking at the code.  Didn't mean to rephrase
a comment in reply to you.  :)

> Suppose the architectures are the same and it's only the mach's
> that are different (say different chip variants) and the variants
> are not compatible.  [This is different than my original question, yes.]
> The relocations are, however, identical between the two chip variants.
> [I'm guessing that's often the case within the same architecture].
> 
> A relocatible link of these two chip variants will yield the error:
> 
> Relocatable linking with relocations from format elf32-foo (foo1.o) to format elf32-foo (foo2.o) is not supported
> 
> Not a very useful error message.
> [ergo my request to include the printable names in the error message]

Agreed.  My first reaction was that bfd_arch_get_compatible should
return true in this case, but on further thought, I suppose it's
reasonable to want to reject input based on eg. ELF e_flags.
Especially since bfd_arch_get_compatible is also used to reject files
when searching.  Hmm, perhaps it would be a good idea to override
bfd_arch_get_compatible with -noinhibit-exec.

> Furthermore, when doing a final link, it succeeds (or gives a warning
> when requested), which is counter-intuitive to the user.

True, but one of the original design goals of BFD was to support
linking different input formats.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre


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