Greetings!
Following your suggestion, I've managed to get the following working
in a readelf like manner, i.e. without bfd:
i386, amd64, alpha, mips, s390, m68k, arm, sparc, ppc, sh4
I'll attack ia64 and hppa when time permits.
I have one question re: mips and alpha. mips appears to be the only
arch without a .plt section, but rather a special MIPS_stubs section,
which are only callable addresses if the gp register is left in its
canonical position. My executable calls _setjmp (for example), and
needs to load, relocate, and execute code that calls _setjmp.
Normally I relocate to the .plt entry in the base executable, but on
mips I leave the gp pointer at its canonical value and use the .got
entry in the base executable for CALL16 relocs. This means I need a
.got entry for each such symbol -- as there are some which my base
executable does not need (or call), but the code to be loaded and
relocated does, I make a dummy function in the base executable which
calls all such symbols as a workaround. Is there any safer way to
ensure that symbols get a .got entry?
On alpha I was unable to do likewise as I could not parse the base
.got section, and in any case, GPRELHIGH/LOW relocs, which can only
handle addresses 32bits away from the gp register, might be too far
away on a 64bit system. Instead, I make my own .got per loaded .o
file, again placing the .plt addresses therein when applicable. There
are a few symbols, however, such as __divq, for which I cannot
generate a .plt entry with a R_ALPHA_JMP_SLOT no matter how I call it
in the base executable. For these, I read the .rela.dyn section, and
place the address assigned therein by ld.so into by own .got table.
This is dangerous, as typical usage might lead to the running memory
image being saved and later reexecuted, perhaps even on a different
machine, and I've just hardcoded a bad address to __divq. Is there
any way to get some sort of trampoline to such functions in the base
executable, with an immovable address, that will be valid no matter
what ld.so decides to do? This is the only machine (thus far) on
which I have this problem.
Take care,
Nick Clifton <ni...@redhat.com> writes:
> Hi Camm,
>
>> $ cat /tmp/hh.c
>> #include<stdio.h>
>>
>> int main(int argc,char *argv[]) {
>> printf("hello\n");
>> return 0;
>> }
>
>> Target: i486-linux-gnu
>
>> $ ./binutils/readelf -R .text /tmp/hh.o
>>
>> Hex dump of section '.text':
>> 0x00000000 5589e583 e4f083ec 10c70424 00000000 U..........$....
>> 0x00000010 e8ebffff ffb80000 0000c9c3 ............
>
> Ah ha! You have chosen a target architecture which just happens not
> use a special reloc to handle function calls. If you have a look at
> the relocs in the hh.o file:
>
> % readelf -r hh.o
> Relocation section '.rel.text' at offset 0x340 contains 2 entries:
> Offset Info Type Sym.Value Sym. Name
> 0000000c 00000501 R_386_32 00000000 .rodata
> 00000011 00000902 R_386_PC32 00000000 puts
>
> You will see that it only uses the R_386_32 (a 32-bit fixed-location
> reloc) and the R_386_PC32 (32-bit PC-relative) relocs. Both of which
> readelf implements because it can find them in debug sections.
>
> If you try compiling your test program for a different architecture,
> say the IA64, then:
>
> % ia64-elf-gcc -c hh.c
> % ia64-elf-readelf -R .text hh.o
> Hex dump of section '.text':
> readelf: Warning: unable to apply unsupported reloc type 134 to
> section .text
> readelf: Warning: unable to apply unsupported reloc type 135 to
> section .text
> readelf: Warning: unable to apply unsupported reloc type 73 to
> section .text
> 0x00000000 00181d0c 80054002 30004280 0167fc8c ......@.0.b..g..
>
> Or the HPPA:
>
> % hppa-linux-gnu-gcc -c hh.c
> % hppa-linux-gnu-readelf -R .text hh.o
> Hex dump of section '.text':
> readelf: Warning: unable to apply unsupported reloc type 2 to
> section .text
> readelf: Warning: unable to apply unsupported reloc type 6 to
> section .text
> readelf: Warning: unable to apply unsupported reloc type 12 to
> section .text
> 0x00000000 6bc23fd9 08030241 081e0243 6fc10080 k.?....A...Co...
>
> Cheers
> Nick
>
>
>
>
--
Camm Maguire c...@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
_______________________________________________
Gcl-devel mailing list
Gcl-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gcl-devel
