Not linking 32-bit and 64-bit objects

Ian Lance Taylor ian@airs.com
Tue Mar 12 16:18:00 GMT 2002


Alan Modra <amodra@bigpond.net.au> writes:

> Depends on what you mean by "legal".  From a BFD viewpoint, where we
> try to link anything with everything, the real problem is that BFD
> currently fails when attempting to process relocs for the foreign
> word size.  The ELF linker should treat these files similarly to
> non-ELF files.  ie. The test at elflink.h:5331
> 
> 	  if (p->type == bfd_indirect_link_order
> 	      && (bfd_get_flavour (p->u.indirect.section->owner)
> 		  == bfd_target_elf_flavour))
> 
> needs to test for wordsize too.

That makes sense to me.  The code in elf_link_input_bfd clearly
assumes that it is reading ELF information which is the same size as
the current backend.

> From a user viewpoint, I'm not sure of the right answer.  I'd guess
> that in most cases where this situation arises, it's because the
> user inadvertently linked against the wrong library.  However, if
> we prohibit this, someone is sure to complain that his "simple"
> object with the wrong word-size won't link.  Maybe I was a little
> hasty telling Andreas to change cpu-i386.c, but let's not revert
> it just yet. :)

The advantage of checking for problems in bfd_arch_get_compatible or
bfd_merge_private_bfd_data is that it permits the user to use the
--no-warn-mismatch option.  Then the default is to give a warning
(bfd_arch_get_compatible) or error (bfd_merge_private_bfd_data) while
still permitting the (sophisticated) user to force the link to
proceed.

Ian



More information about the Binutils mailing list