Re: Linking nominally incompatible object files

[Nick Clifton <nickc at redhat dot com>]

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