Bug 539590 - gdb can't call some functions
Summary: gdb can't call some functions
Alias: None
Product: Fedora
Classification: Fedora
Component: gdb
Version: 12
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jan Kratochvil
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-11-20 17:03 UTC by Tom Horsley
Modified: 2010-07-20 18:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-04-04 08:50:22 UTC

Attachments (Terms of Use)
ifunc implementation #1. (14.36 KB, patch)
2009-11-23 21:39 UTC, Jan Kratochvil
no flags Details | Diff

Description Tom Horsley 2009-11-20 17:03:52 UTC
Description of problem:

The fedora 12 x86_64 gdb experience:

# gdb ./fact
GNU gdb (GDB) Fedora (7.0-3.fc12)
...yadda, yadda, yadda...
(gdb) b main
Breakpoint 1 at 0x400593: file fact.c, line 19.
(gdb) r 7
Starting program: fact 7

Breakpoint 1, main (argc=2, argv=0x7fffffffe708)
    at fact.c:19
19         for (i = 1; i < argc; ++i) {
(gdb) p strlen("xyzzy")
$1 = -509088576

I'm pretty sure the string "xyzzy" is not -509,088,576
bytes long :-).

The fedora 11 x86_64 gdb experience:

zooty> gdb ./fact
GNU gdb (GDB) Fedora (
...yadda, yadda, yadda...
(gdb) b main
Breakpoint 1 at 0x400593: file fact.c, line 19.
(gdb) r 7
Starting program: fact 7

Breakpoint 1, main (argc=2, argv=0x7fffffffe2b8)
    at fact.c:19
19         for (i = 1; i < argc; ++i) {
(gdb) p strlen("xyzzy")
$1 = 5

I was right! It is actually 5 bytes long.

P.S. The program "fact" is unimportant, any old hello world sort
of app dynamically linked with libc will do.

Version-Release number of selected component (if applicable):

How reproducible:
Oh, it is gonna happen every time, for strlen and several other
similar functions (strcpy, etc).

Steps to Reproduce:
1.see above
Actual results:
ridiculous nonsense

Expected results:
actual length of string

Additional info:
I know exactly what is happening here, but why should I spare
the gdb maintainers the thrill of the discovery of the true
horror the latest glibc "improvements" have foisted on long
suffering debugger maintainers? :-).

Comment 1 Phil Muldoon 2009-11-20 21:39:28 UTC
This might be cross-pollination of a cause involving conditional breakpoints involving an inferior function call smashing the breakpoint struct. I've been looking a little at this today, and the value returned from inferior function call is bogus. 


If you have a theory the the cause, please by all means expound on it! It's all good ;)

Comment 2 Tom Horsley 2009-11-20 22:35:04 UTC
Nope, this has nothing to do with conditional breakpoints. If you
do an 'nm' on libc.so, you will see the functions that gdb cannot
call have an 'i' printed in front of the symbol.

If you disassemble the code at &strlen, you find no code that
could possibly take an argument and return a string length.

If you follow these clues around for several hours of google
searching, you will find the STT_GNU_IFUNC symbol type and
the assembler directive .type @gnu_indirect_function in various
patches applied to the glibc code.

In those patches, you will also find that glibc now has
47,621 different versions of strlen, each optimized for a
different architecture variation, because, after all, it
is vital to provide a 1 nanosecond speed improvement in routines
that typical programs spend 0.001% of their time in at the cost
of complicating the maintenance of glibc and debuggers
by a factor of at least 100.

Anyway, it seems like the dynamic linker checks for these
indirect function entries when it is looking up symbols
to resolve .plt entries, and when it finds one, rather than
stashing the symbol value as the address of the function,
it *calls* the funtion, which returns a pointer to the best
version of of the 47,621 alternate strlens to use on the
current architecture.

So the symbol named "strlen" is indeed a function, but it is
a function of no arguments which returns a pointer to another
function (the one you really want).

God help us all when the security boys get wind of this
dynamic linker feature - then they can randomly pick different
implementations of all the glibc functions at runtime :-).

Comment 3 Jan Kratochvil 2009-11-23 21:39:46 UTC
Created attachment 373246 [details]
ifunc implementation #1.

Comment 4 Fedora Update System 2009-11-25 10:53:27 UTC
gdb-7.0-7.fc12 has been submitted as an update for Fedora 12.

Comment 5 Fedora Update System 2009-11-27 21:59:06 UTC
gdb-7.0-7.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 6 Fedora Update System 2010-01-21 21:49:15 UTC
gdb-7.0.1-28.fc12 has been submitted as an update for Fedora 12.

Comment 7 Fedora Update System 2010-07-20 18:07:36 UTC
gdb-7.0.1-49.fc12 has been submitted as an update for Fedora 12.

Note You need to log in before you can comment on or make changes to this bug.