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