[Bug gdb/29989] PowerPC, gdb fails to stop at printf call

["cel at linux dot ibm.com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #4 from Carl E Love <cel at linux dot ibm.com> ---
Digging into the issue further, the issue is not limited to the printf function
but all of the symbols for the IEEE 128-bit floating point functions that are
redirected in glibc.  

PowerPC supports the IBM 128-bit floating point format and the IEEE 128-bit
floating point format.  The IEEE 128 bit support redirects the various function
calls to the ieee128 versions of the functions.  For example, the printf
function gets linked to the __printfieee128 function at linking time.   Gdb is
not aware of the ​__printfieee128 symbol was redirected from the original
printf symbol so it only sets a breakpoint in the standard printf function. 
GDB fails to break in the redirected printf function.  The printf function is
just one of about 200 IEEE128 bit functions that get remapped for PowerPC.

Ulrich and I have looked at fixing this in gdb by creating hidden symbols for
printf that points to the __printfieee128 function.  Although it is possible to
do, in general it is really messy/hard to do because because of the naming
scheme that was used. The original function was mapped to an ieee128 bit
function with one of the following mappings:

  foo    ->    __fooieee128
  fool   ->    __fooieee128
  foo    ->    __newnameieee128
  foo_r  ->    __fooieee128_r

In GDB, you have to do the reverse mapping from to determine what the original
function name "foo" so you can create a hidden symbol for "foo" that points to
the IEEE 128 bit symbol "__fooiiieee128".  We have tried to come up with a
simple reverse mapping algorithm, but since __fooieee128 can map back to either
foo or fool you have to search the entire list of mappings to determine what
the original name was.  Note, there are also some existing symbol names with
ieee128 in them that are not the result of redirecting function foo to its IEEE
128 equivalent function.  These also cannot be eliminated without going thru
the list of known symbol names that have been redirected.  

A proof of concept patch in gdb which takes the symbol and searches the list of
200+ redirected function names to determine the original symbol name was done
and works.  The issue is maintaining the list of 200+ function mappings in gdb
is fragile and not considered an acceptable solution.

The feeling is the right thing to do is to have glibc emit a local symbol in
the library binary, i.e. printf that points to the redirected symbol, i.e.
__printfieee128.  When the user types "break printf" GDB will set a breakpoint
in the original printf function and in the __printfieee128 function via the
local printf symbol in the glibc library.  

Basically, have glibc create the hidden symbol for each of the 200 or so
redirected functions rather than having gdb create the hidden symbol as was
done in the proof of concept patch.  The advantage of having glibc add the
local symbol to the library binary is it already knows what symbols are being
redirected and gdb doesn't have to maintain a list of mappings.  

The new redirected symbols need to be dynamic symbols in case only the stripped
binary is available.

-- 
You are receiving this mail because:
You are on the CC list for the bug.