This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linking nominally incompatible object files


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]