This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: bfd_get_relocated_section_contents on hppa and ia64
Greetings!
Nick Clifton <nickc@redhat.com> writes:
> 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).
Thanks so much.
>
>
>> 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 ../.....
>
Bizarre:
camm@localhost:~/debian/gcl/binutils-2.20.1$ cat /tmp/hh.c
#include <stdio.h>
int main(int argc,char *argv[]) {
printf("hello\n");
return 0;
}
camm@localhost:~/debian/gcl/binutils-2.20.1$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.3-7' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --enable-targets=all --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Debian 4.4.3-7)
camm@localhost:~/debian/gcl/binutils-2.20.1$ gcc -c /tmp/hh.c -o /tmp/hh.o
camm@localhost:~/debian/gcl/binutils-2.20.1$ ./binutils/readelf -R .text /tmp/hh.o
Hex dump of section '.text':
0x00000000 5589e583 e4f083ec 10c70424 00000000 U..........$....
0x00000010 e8ebffff ffb80000 0000c9c3 ............
Really hope this really works.
Take care,
>
> Cheers
> Nick
>
>
>
>
--
Camm Maguire camm@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah