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] |
Agreed - it is quite strange.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.
I notice now that in my "new" file bfd/elf32-v800.c (*derived* from, notThis 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.
replacing elf32-v850.c!) the token "R_V850_22_PCREL" appears only in the
macro call to HOWTO - IOW it is otherwise unhandled.
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.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?
Seriously, what sort of circumstances could cause ld to bail like this?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.
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?
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?
Cheers Nick
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |