Re: Linking nominally incompatible object files

[Bernd Jendrissek <berndj at prism dot co dot za>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, May 05, 2004 at 05:30:37PM +0100, Nick Clifton wrote:
> >So I have a mix of GCC-compiled v850 object files, and Green Hills v800
> >(what I've called my "new" target) libraries.  When I link them all
> >together, I get:
> >
> >lt-ld-new: warning: v850 architecture of input file `aim.o' is 
> >incompatible with v850e output
> >lt-ld-new: warning: v850 architecture of input file `circbuf.o' is 
> >incompatible with v850e output
> >
> Assuming that "lt-ld-new" is the GNU linker then this message is arising 

Yes, lt-ld-new is a shell script that invokes the newly built GNU ld
with the appropriate LD_LIBRARY_PATH hackery so that it uses the
libraries it just built instead of those installed in /usr/lib.

> because the machine numbers of the two files are different.  These 
> numbers are held in the e_machine field of the ELF header and the GNU 
> linker is expecting one of the values defined in the bfd/archures.c file 
> (bfd_mach_v850, bfd_mach_v850e, bfd_mach_v850e1).  The output file has 
> its e_machine value filled in by using the value from the very first 
> object file on the linker's command line.  This is usually a file like 
> crt0.o.  So in this case the linker is telling you that the crt0.o file 
> (or whichever is the first file in the link) is for a different version 
> of the v850 than the aim.o file.

Yes, I got that, and I'm glad it's a warning and not an error.

> >reloc type 2 not SUPPORTED
> >
> >The weird thing is, that aim.o is generated by the v850 toolchain, so
> >its relocs cannot possibly be completely alien (if I link with the
> >v850-ld and remove all the v800 libraries, the errors are "undefined
> >reference", not "unsupported relocation").
> >
> Reloc 2 is for a function call.

It is for v850 indeed.  Which is why I'm surprised that the linker
claims it's *not* supported.  (And I did configure with
- --enable-targets=all.)

> So if you remove the libraries then you 
> are probably removing the definition of the function being called and 
> hence the failure changes to "undefined reference".  I am not sure why 
> you are getting the message that the reloc is not supported.  I think 
> that some further investigation is needed.

Yes.  Some more data:

I notice now that in my "new" file bfd/elf32-v800.c (*derived* from, not
replacing elf32-v850.c!) the token "R_V850_22_PCREL" appears only in the
macro call to HOWTO - IOW it is otherwise unhandled.  Fine, because the
Green Hills toolchain uses what it calls "R_V850_22_PCREL", reloc 22.

It's as if the linker is looking at the v850 object file with my hacked
v800 backend!  And yet, the v850 backend is still there.  Indeed, the
error message ("reloc type 2 not SUPPORTED") MUST be from my v800
target, as the fprintf is commented out in the GNU version.

> >Is the linker supposed to interpret the relocs based on the input file
> >format (would be nice) or based on the output file format?
>
> Neither and both.  It is supposed to interpret them based on the target 
> architecture that it was built to support.  When it is built to support 
> more than one architecture then it is supposed to select the relocs that 
> is supports based upon the input file that it is processing.

So if I configured my binutils with --enable-targets=all, the linker
*should* interpret the relocs based on the input file in which they
appear?  IOW those R_*V850*_22_PCREL relocs should be getting handled
just fine by the *v850* backend... but they evidently aren't.  :(

> (It is also allowed to refuse to link together files of different
> architectural types if it thinks that it cannot handle this).

You mean... you mean... in some circumstances ld *cannot* just read my
mind and DTRT?  What sort of crummy tool is THAT??!?  :)

Seriously, what sort of circumstances could cause ld to bail like this?
I would have thought that relocs always operate on bits in the same
object file as where the relocs are.  Isn't that the whole point of BFD,
to abstract object files as just BFDs which can then be linked together
in an architecture-independent way?

If I wanted to look at the logic that decides how input file relocs
should be handled, where would I look?  (What I want to check: whether
ld will *really* change its interpretation of relocs on a per input file
basis.)

Hah!  Look at bfd/elflink.h:

elf_link_input_bfd():
  [declarations]

  output_bfd = finfo->output_bfd;
  bed = get_elf_backend_data (output_bfd);
  relocate_section = bed->elf_backend_relocate_section;

So, because my new linker is configured to produce v800 *output*, all
*input* object files have their relocs interpreted as v800 relocs as
well!  Now, what do I do about it?  Hah!  I do this:

- --- binutils/bfd/elflink.h.borig Wed Jan 14 23:07:43 2004
+++ binutils/bfd/elflink.h       Wed May  5 19:39:49 2004
@@ -4678,7 +4678,7 @@
   struct elf_link_hash_entry **sym_hashes;
 
   output_bfd = finfo->output_bfd;
- -  bed = get_elf_backend_data (output_bfd);
+  bed = get_elf_backend_data (input_bfd);
   relocate_section = bed->elf_backend_relocate_section;
 
   /* If this is a dynamic object, we don't want to do anything here:

And now the only "not SUPPORTED" relocs are the v800 ones for which I
haven't yet added support.  What did I break?

> >Should I just give up now, while I can, before I involuntarily end up as
> >a BFD hacker?
> >
> Welcome to the dark side :-)

I'm actually finding it a lot easier than I had originally imagined; I
guess this is due to the plentiful helpful comments all over the code.
Thanks for that, people!

- -- 
http://voyager.abite.co.za/~berndj/ (f1084a555d2098411cff4cefd41d2e2a1c85d18c)
I've generally found that the fastest way to get the right answer on the net
is to confidently assert the answer you believe to be right; those who know
will immediately correct you, while if you just ask, often no answers arrive.
All it requires is a willingness to look bad on occasion.
                                               - Joe Buck on gcc@gcc.gnu.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAmS8u/FmLrNfLpjMRAgtIAJ4u5L8kzIelBvqWZjgSlD4GrV7wrQCcD2gJ
6oO0dOQiWSXilHkMAWi3KZQ=
=fz+6
-----END PGP SIGNATURE-----