This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

pending/1327: fake symbols to aid debugging


>Number:         1327
>Category:       pending
>Synopsis:       fake symbols to aid debugging
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   unknown
>Arrival-Date:   Fri Aug 08 02:28:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        
>Organization:
>Environment:
>Description:
 PowerPC64 (and other architechures) use linker stubs for various things,
 most notably to make calls to functions in shared objects.  Typical
 disassembly looks like:
 
 the stub
   7ea138:       3d 82 00 01     addis   r12,r2,1
   7ea13c:       f8 41 00 28     std     r2,40(r1)
   7ea140:       e9 6c 11 88     ld      r11,4488(r12)
   7ea144:       e8 4c 11 90     ld      r2,4496(r12)
   7ea148:       7d 69 03 a6     mtctr   r11
   7ea14c:       e9 6c 11 98     ld      r11,4504(r12)
   7ea150:       4e 80 04 20     bctr
 
 call to stub
   87d6f0:       e8 7e 80 90     ld      r3,-32624(r30)
   87d6f4:       4b f6 ca 45     bl      7ea138 <._init+0xe9b8>
   87d6f8:       e8 41 00 28     ld      r2,40(r1)
 
 Note the meaningless symbol given as target for the "bl".  Now, if you
 know enough about the ABI, it's possible to figure out which function is
 being called, but that's a pain.  In the case of PowerPC64 you need to
 a) Find the value of r2 by looking at the calling function's opd entry.
    (with multiple GOT/TOC r2 is not fixed).
 b) Perform the calculation done by the stub to find the plt entry
    address. 
 c) Search the relocs to find the one for this particular plt entry.
    The symbol on the reloc gives the function name.
 
 I waste enough time doing this that I figure it's worth doing something
 about it.  My first idea, already implemented, was to have the linker
 emit extra symbols to identify the stubs.  This works well but bloats
 the symbol table and isn't on by default.  A better idea would be to
 create the stub symbols on the fly.  With that in mind, I propose to
 add two new bfd functions
 
 long bfd_get_fake_symtab_upper_bound (bfd *abfd);
 long bfd_canonicalize_fake_symtab (bfd *abfd, asymbol **buf);
 
 analogous to bfd_get_symtab_upper_bound and bfd_canonicalize_symtab.
 
 Comments?
 
 -- 
 Alan Modra
 IBM OzLabs - Linux Technology Centre
 
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]