[Bug translator/13222] New: process.plt only supports x86

[Bug translator/13222] New: process.plt only supports x86

[scox at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13222

             Bug #: 13222
           Summary: process.plt only supports x86
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap@sourceware.org
        ReportedBy: scox@redhat.com
    Classification: Unclassified


PPC plt handling

1. reference to foo@plt
2. load r11 with a .plt memory location that initially points to glink
3. branch -> glink -> __glink_PLTresolve -> _dl_runtime_resolve
4. this resolves so that the .plt memory location now points to foo
5. hereafter a foo@plt reference
6. loads r11 with the .plt memory location that is now the address of foo

- there is one entry in .plt and glink for each symbol
- the relocations are with respect to the .plt
- the @plt code snippet entries are in the text section

X86 plt handling

1. reference to foo@plt
2. indirect jump from contents of .got.plt to second instruction in foo@plt
3. push an id and branch _dl_runtime_resolve
4. this resolves so that .got.plt location now points to foo
5. hereafter a foo@plt reference
6. indirect jumps to the .got.plt memory location that is now the address of
foo

- the relocations are with respect to the .plt
- the @plt code snippet entries are in the .plt section
- .got.plt (_GLOBAL_OFFSET_TABLE_) somewhat analagous to ppc .plt

stap .plt handling

iterate_over_plt (currently only supports x86) runs through each entry in the
.plt section, uses the relocations to find what symbol an entry is for and does
a callback.  For ppc this strategy will not work since for ppc the .plt
contains only the address to be branched to, the plt code snippets are in the
.text section.  It would be necessary to scan the elf symbol table for the
@plt entries

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug translator/13222] process.plt only supports x86

[scox at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13222

Stan Cox <scox at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pmachata at redhat dot com

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/13222] process.plt only supports x86

[scox at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13222

--- Comment #1 from Stan Cox <scox at redhat dot com> ---
Comments from Petr Machata who added ppc plt support to ltrace:
PPC PLT slots themselves are only used on first call, which means you never hit
them on prelinked binary or often don't hit them when attaching to a running
one.
ltrace goes to great lengths to simulate the as-if behavior, meaning as-if ppc
had sane PLT tables.  It unprelinks stuff, singlestepping through the dynamic
linker.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/13222] process.plt only supports x86

[scox at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13222

--- Comment #2 from Stan Cox <scox at redhat dot com> ---
Detailed info on ppc plt support can be found in the top comments in the ltrace
ppc plt source: tree/sysdeps/linux-gnu/ppc/plt.c

-- 
You are receiving this mail because:
You are the assignee for the bug.