Linking nominally incompatible object files

Linking nominally incompatible object files

[Bernd Jendrissek]

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

Hello, me again.

While I have a v850 toolchain (GCC + binutils), I'm working on hacking a
copy of the v850 bits so that I can link in libraries supplied by Green
Hills (EM_V800 not EM_V850, different relocs).

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:

+ /mnt/disk2/src/binutils-build/ld/ld-new -e __start -L../../../../../SDK/Lib ../../../../../SDK/Lib/crtPulsarPlus.o -lstartup -lsys
 -lind -larch -lsedgnoe -lansi ../../../../../SDK/Lib/lCore.a -o emv.elf aim.o circbuf.o emv.o file.o mafif.o main.o sps.o swevent_m
an.o tlv.o trace.o utils.o ../../../../manapp/Source/Common/data_store.o ../../../../manapp/Source/Common/event.o ../../../../manapp
/Source/Common/mailbox.o ../../../../manapp/Source/Common/memory.o
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

...

reloc type 2 not SUPPORTED
aim.o(.text+0x2c): In function `AimEventHandler':
/mnt/disk2/src/emv/sc5000/dev/PayApp/Emv/MafApp/Source/aim.c:42: internal error: unsupported relocation error

...

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

Is the linker supposed to interpret the relocs based on the input file
format (would be nice) or based on the output file format?  Because,
what seems to be happening now, is that the linker sees relocs in an
input file of format A, but those relocs get misinterpreted as relocs in
format B, and I get segfaults.

Should I just give up now, while I can, before I involuntarily end up as
a BFD hacker?

- -- 
http://voyager.abite.co.za/~berndj/ (f1084a555d2098411cff4cefd41d2e2a1c85d18c)
"years from now, we'll look back on this, laugh nervously and quickly
change the subject" - lee
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAlSNb/FmLrNfLpjMRAmtFAKCPGToQjpHxiFPf+2B3k90BCKOT7ACcCQT/
J3LhFhbb9mtnoUTRhOdGOk4=
=1Mxe
-----END PGP SIGNATURE-----

Re: Linking nominally incompatible object files

[Nick Clifton]

Hi Bernd,

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

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

>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.  (It is 
also allowed to refuse to link together files of different architectural 
types if it thinks that it cannot handle this).

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

Cheers
  Nick

Re: Linking nominally incompatible object files

[Bernd Jendrissek]

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

Re: Linking nominally incompatible object files

[Nick Clifton]

Hi Bernd,

>>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. 
>  
>
Agreed - it is quite strange.

>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. 
>
This is probably not quite true.  If the "special_function" field is set 
to "bfd_elf_generic_reloc" then the generic reloc handling code in 
bfd/elf.c will handle the processing of the reloc.



>>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?
>
Yes - but only if it can tell the difference between the input file 
types.  In particular if both the GNU toolchain and the Green Hills 
toolchain are using the same machine number in the ELF header's 
e_machine field then the linker will not be able to distinguish them.  
(See elf_object_p() in bfd/elfcode.h).  Also note that for a lot of 
targets with related variants (eg ARM, MIPS etc) a supplementary 
mechanism is used to distinguish between variants.  This can be flags in 
the e_flags of the header or a special section in the object file 
containing information about how the file was compiled.  The v850 port 
uses the flags method.  (See bfd/elf32-v850.c:v850_elf_object_p()).  If 
this function is unable to distinguish between Green Hills object files 
and GNU object files then it will be unable to set the correct (internal 
BFD) machine number and then the linker will not be able to determine 
which kind of relocs it should be processing.


>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?
>  
>
Yes - but the *meaning* of a reloc is not encoded within the reloc 
structure stored in the object file.  All the linker has to go on is a 
reloc number.  (Plus the knowledge of the target architecture of the 
object file).  If the linker encounters a reloc number that it has not 
been programmed to handle (for a given architecture) then all it can do 
it complain.  It has no way to derive the semantics of the reloc.

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

In theory, only the assumption that input_architecture == 
output_architecture.  Well actually a lot more than that.  For example 
the decision about whether relocs should be copied into the output file 
is specific to the output file architecture 
(bed->elf_backend_emit_relocs).  Or the routine to be used to emit the 
relocated section (bed->elf_backend_write_section).  It looks like 
elf_link_input_bfd() needs some tidying up to remove assumptions about 
input and output architectures.

Cheers
  Nick

Re: Linking nominally incompatible object files

[Bernd Jendrissek]

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

On Thu, May 06, 2004 at 02:36:27PM +0100, Nick Clifton wrote:
> >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. 
> >
> This is probably not quite true.  If the "special_function" field is set 
> to "bfd_elf_generic_reloc" then the generic reloc handling code in 
> bfd/elf.c will handle the processing of the reloc.

I'm not going to worry about this; it's square peg round hole now - the
relocs were getting interpreting by the wrong backend, AFAICT and IMHO.
Fix that (trying to avoid breaking other stuff), and the problem goes
away.

> >>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?
> >
> Yes - but only if it can tell the difference between the input file 
> types.  In particular if both the GNU toolchain and the Green Hills 
> toolchain are using the same machine number in the ELF header's 
> e_machine field then the linker will not be able to distinguish them.  

It seems able to distinguish them.  Is e_machine the field that holds
EM_V800 or EM_V850 or EM_<machine> in general?  I'm only asking because
the machine type seems to be encoded somewhere else as well: I hex-edit
my GCC-compiled object file (carefully avoiding generating relocs; just
symbols) to change the EM_V850 to EM_V800 at file offset 0x12, which
makes the Green Hills linker happy enough to link the file in, but their
"gdump" utility still says
 e_machine =  <<< unknown V800 machine type (0x24) >>>
but their own object files have exactly the same 0x24!

> (See elf_object_p() in bfd/elfcode.h).  Also note that for a lot of 
> targets with related variants (eg ARM, MIPS etc) a supplementary 
> mechanism is used to distinguish between variants.  This can be flags in 
> the e_flags of the header or a special section in the object file 
> containing information about how the file was compiled.

Thanks; I'll check that out if/when I fold my hackery back into the v850
bits.  In the v850 case, the use is to subtly influence the set of valid
instructions, no?  Or is there much beyond that?

> The v850 port uses the flags method.  (See
> bfd/elf32-v850.c:v850_elf_object_p()).  If this function is unable to
> distinguish between Green Hills object files and GNU object files then
> it will be unable to set the correct (internal BFD) machine number and
> then the linker will not be able to determine which kind of relocs it
> should be processing.

Actually, they differ more fundamentally: ELF_MACHINE_CODE has to be
EM_V800 (not EM_V850) to even start interoperating with Green Hills.

> >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?
> >
> Yes - but the *meaning* of a reloc is not encoded within the reloc 
> structure stored in the object file.  All the linker has to go on is a 
> reloc number.  (Plus the knowledge of the target architecture of the 
> object file).  If the linker encounters a reloc number that it has not 
> been programmed to handle (for a given architecture) then all it can do 
> it complain.  It has no way to derive the semantics of the reloc.

Yes, I understood that - that's why the reloc interpretation should be
delegated the the backend *for that input file*, no?  You later mention
the possibility of only the output bfd knowing whether to copy relocs or
not; that may throw a spanner in my works.

> >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?
> 
> In theory, only the assumption that input_architecture == 
> output_architecture.

In "theory"?  Do you think that assumption is manifested anywhere?

> Well actually a lot more than that.  For example the decision about
> whether relocs should be copied into the output file is specific to
> the output file architecture (bed->elf_backend_emit_relocs).

I'm afraid I'm lost now; I'll have to try following
elf_backend_emit_relocs again later.

> Or the routine to be used to emit the relocated section
> (bed->elf_backend_write_section).  It looks like elf_link_input_bfd()
> needs some tidying up to remove assumptions about input and output
> architectures.

Am I the only one who's ever tried to link together object files of
differing BFD backends?

- -- 
http://voyager.abite.co.za/~berndj/ (f1084a555d2098411cff4cefd41d2e2a1c85d18c)
I have neither the need, the time, or the inclination to put words into your
mouth. You are perfectly capable of damaging your reputation without any help
from me.                   --Richard Heathfield roasts a troll in comp.lang.c
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAm1B//FmLrNfLpjMRAoa8AJ0cuDwvQ/qnab2pGlFCcy2OSC9VYACgoQib
6OKlTDTzu8gZLFecs5twfJE=
=RLBj
-----END PGP SIGNATURE-----

Re: Linking nominally incompatible object files

[Nick Clifton]

Hi Bernd,

> <>It seems able to distinguish them. Is e_machine the field that holds
> EM_V800 or EM_V850 or EM_<machine> in general?

Yes.

> <> I'm only asking because
> the machine type seems to be encoded somewhere else as well: I hex-edit
> my GCC-compiled object file (carefully avoiding generating relocs; just
> symbols) to change the EM_V850 to EM_V800 at file offset 0x12, which
> makes the Green Hills linker happy enough to link the file in, but their
> "gdump" utility still says
> e_machine = <<< unknown V800 machine type (0x24) >>>
> but their own object files have exactly the same 0x24!

It may be the changing of the relocs that makes the linker happy.  I 
suspect that the gdump utility is checking some other fields in the ELF 
header as well as the e_machine field and that this is why it is 
complaining.  (Although really it ought to say so, if this is the 
case).  Likely candidates are the e_version and e_flags fields.

>>(See elf_object_p() in bfd/elfcode.h).  Also note that for a lot of 
>>targets with related variants (eg ARM, MIPS etc) a supplementary 
>>mechanism is used to distinguish between variants.  This can be flags in 
>>the e_flags of the header or a special section in the object file 
>>containing information about how the file was compiled.
>>    
>>
>
>Thanks; I'll check that out if/when I fold my hackery back into the v850
>bits.  In the v850 case, the use is to subtly influence the set of valid
>instructions, no?  Or is there much beyond that?
>  
>
No that is about it.

>>Yes - but the *meaning* of a reloc is not encoded within the reloc 
>>structure stored in the object file.  All the linker has to go on is a 
>>reloc number.  (Plus the knowledge of the target architecture of the 
>>object file).  If the linker encounters a reloc number that it has not 
>>been programmed to handle (for a given architecture) then all it can do 
>>it complain.  It has no way to derive the semantics of the reloc.
>>    
>>
>
>Yes, I understood that - that's why the reloc interpretation should be
>delegated the the backend *for that input file*, no? 
>

Yes.  (ie I agree with you).

> You later mention
>the possibility of only the output bfd knowing whether to copy relocs or
>not; that may throw a spanner in my works.
>  
>

Right, but this was referring to whether the output file architecture 
needs to preserve (or transform) some of the relocs in the input files.  
For some targets, eg ones using shared libraries, some relocs are not 
processed by the linker but held in the executable and processed at 
program-load-time.

>>>And now the only "not SUPPORTED" relocs are the v800 ones for which I
>>>haven't yet added support.  What did I break?
>>>      
>>>
>>In theory, only the assumption that input_architecture == 
>>output_architecture.
>>    
>>
>
>In "theory"?  Do you think that assumption is manifested anywhere?
>  
>

Probably.  You see normally you would not expect to be able to link 
together object files for different architectures.  eg you would not 
expect to be able link together ARM object files and MIPS object files.  
Hence the linker generally assumes that it is linking only one kind of 
input file.  The linker does have some support for generating an output 
file that is in a different format from the input file, but this is 
really intended for transforming the executable into some kind of ROM 
friendly format (eg Intel iHex).  This only works if the output format 
is architecture neutral, and it does not work for all targets either.  
So for most users it is simpler to linker together identical 
architecture input files to form a matching format output file and then, 
if necessary, use the objcopy utility to change the file format of the 
executable.

In your case, where the underlying architecture is the same, and you are 
just trying to handle different reloc encoding schemes, the linker 
should be able to adapt.  There is no theoretical reason why the linker 
cannot handle both Green Hills and GNU style relocs, but I do not know 
if anyone has tried something like this before, so you may well run into 
difficulties.

Cheers
  Nick