bfd_get_relocated_section_contents on hppa and ia64

[Nick Clifton]

Hi Camm,

>>> Where is all this stuff documneted, BTW?
> I guess I was referring to the relocs that *weren't* in readelf.c.

Ah - sorry - most relocs are architecture specific.  Thus you have to 
refer to the ABI documentation for a given architecture in order get the 
official definitions.

You can gain some insight into the purpose and behaviour of a target's 
individual relocs by looking at the "elf....<target>.c" file in the bfd/ 
directory.  Near the start of these files there is usually a declaration 
of an array of reloc_howto_type entries, one per reloc supported by that 
particular target.  These entries show various things like how many bits 
they affect, whether the value they produce is PC-relative and so on. 
Also in these "elf...<target>.c" files there will usually be a function 
called something like <target>_final_link_relocate which is responsible 
for implementing those relocs which cannot be handled by the generic 
code.  (The generic code in the BFD library uses the information in the 
reloc_howto_type array to implement the relocs).


> I had another look at readelf, and looped over 'readelf -R $i foo.o'
> on my code looking for unsupported reloc warnings.  I found none, to
> my surprise,

Hmmm, that is strange.  What was $i set to ?  If it was not a section 
that had relocations associated with it then that would explain the 
problem.  I this test with a small example on my local machine and it 
appears to work as expected:

   % gcc -c hello.c
   % readelf -R .text hello.o
   Hex dump of section '.text':
   readelf: Warning: unable to apply unsupported reloc type 28 to 
section .text
   readelf: Warning: unable to apply unsupported reloc type 40 to 
section .text
     0x00000000 00482de9 04b08de2 14009fe5 feffffeb .H-.............
     0x00000010 0030a0e1 0300a0e1 04d04be2 0048bde8 .0........K..H..
     0x00000020 1eff2fe1 00000000                   ../.....


Cheers
   Nick