gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: bfd_get_relocated_section_contents on hppa and ia64


From: Camm Maguire
Subject: [Gcl-devel] Re: bfd_get_relocated_section_contents on hppa and ia64
Date: Thu, 26 Aug 2010 15:44:46 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

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 <address@hidden> 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 address@hidden
>
> 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                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

[Prev in Thread] Current Thread [Next in Thread]