gdb 6.0 with nptl glibc

[mulicheng]

In the info page for gdb under threads, I read the following:

_Warning:_ These facilities are not yet available on every GDB
configuration where the operating system supports threads. If
your GDB does not support threads, these commands have no effect.
For example, a system without thread support shows no output from
`info threads', and always rejects the `thread' command, like this:

(gdb) info threads
(gdb) thread 1
Thread ID 1 not known. Use the "info threads" command to
see the IDs of currently known threads.


My system is 2.6.x kernel with glibc 2.3.2-r9+nptl and gdb 6.0.

I was under the impression that gdb 6.0 should have no problem with nptl. Unfortunately, I get the output as described above. Furthermore, If I set a breakpoint someplace where a different thread will find it, gdb terminates the program. Is there anything special you have to do?

Anyone have this type of system working properly and are able to debug a program with multiple threads?

[()]

I do some multi threaded programming, but normally I don't set breakpoints within the other thread, since its meant to operate in realtime (audio). But now that you mention it, GDB does exit when the breakpoint is hit within the thread procedure ('Program terminated with signal SIGTRAP, Trace/breakpoint trap'). Maybe a bug within NPTL? GDB doesn't normally inform of started threads either, as it used to do with LinuxThreads.

Its funny you should ask about this now, since I was stepping through NPTL code yesterday in order to track down a possible bug, NPTL ignores scheduling attributes, it turns out these attributes (set with pthread_attr_setsched*) are blatantly overlooked. Its such an obvious error, and I think it was already reported on the fedora-devel list in february, so maybe theyre aware of it by now? Where should I eventually file this bug you think, Fedora (are there any fora dedicated to NTPL development)?

Edit: Seems Mr. Drepper has addressed the attribute bug at least in NPTL CVS.

[mulicheng]

I do some multi threaded programming, but normally I don't set breakpoints within the other thread, since its meant to operate in realtime (audio). But now that you mention it, GDB does exit when the breakpoint is hit within the thread procedure ('Program terminated with signal SIGTRAP, Trace/breakpoint trap'). Maybe a bug within NPTL? GDB doesn't normally inform of started threads either, as it used to do with LinuxThreads.

That's exactly what I get. It all works fine for me w/ out NPTL, with however, no thread creation is noticed by gdb.

Its funny you should ask about this now, since I was stepping through NPTL code yesterday in order to track down a possible bug, NPTL ignores scheduling attributes, it turns out these attributes (set with pthread_attr_setsched*) are blatantly overlooked. Its such an obvious error, and I think it was already reported on the fedora-devel list in february, so maybe theyre aware of it by now? Where should I eventually file this bug you think, Fedora (are there any fora dedicated to NTPL development)?

I haven't noticed any bugs about this in the bug tracker. I wonder if it would be possible to recompile glibc with a later version of NPTL and if that would fix the issue. Unfortunately, I really need to debug my program quickly instead of debug gdb w/ threads. Maybe someone has already tackled this issue and can post a solution.

[()]

I am recompiling a patched (diffed from latest NPTL CVS) glibc right now, I doubt it will help with debugging though ... Btw, I think GDB would report thread creation when I had compiled glibc with debug information, in fact it reported a new LWP (the main thread?) once I started the program (before I got to pthread_create).

[mulicheng]

I recompiled glibc like this:

FEATURES="nostrip" USE="debug" emerge glibc

That fixed my problem.

[()]

Ok, so debugging information did the trick. Good to know.

[tyreth]

I recompiled glibc like this:

FEATURES="nostrip" USE="debug" emerge glibc

That fixed my problem.

Completely curiosity, but how did you work out to do this to solve the problem?

[mulicheng]

Completely curiosity, but how did you work out to do this to solve the problem?

Well, I thought it might be something to do with no debugging information in the nptl library. Got the following information from gentoolkit's euse utility:

Code: Select all

# euse -i debug
debug [-] [ ] [G] Tells configure and the makefiles to build for debugging.
                  Effects vary acrosss packages, but generally it will at
                  least add -g to CFLAGS. Remember to set FEATURES+=nostrip
                  too.

I tried it and it worked thankfully.

[cjensen]

i'm really interested in the solution as well. if you don't mind i have a couple questions. i've browsed gdb's web page but didn't find anything that addressed these problems.

i don't understand why glibc needs to be compiled with debug info. why would that affect gdb's thread debugging capabilities? was this an issue with the older linuxthreads ? is there a plan to fix this in the near future? i dunno...i dont like the idea of running glibc in debug (wouldn't that potentially slow down the rest of the system)? would there be a way of having 2 versions of glibc and gcc and being able to switch easily between them?

while were at it (off topic), did anyone notice that gcc 3.3 produces huge objects when compiled with debug info? i refer to an earlier post i made:

http://forums.gentoo.org/viewtopic.php? ... ht=#563441

now that gcc 3.3 has been unmasked i'm getting the same problems as i did before. the library i'm developping quadrupled in size when compiled with debug....

in any case thanks for the fix.
Chris

Completely curiosity, but how did you work out to do this to solve the problem?

Well, I thought it might be something to do with no debugging information in the nptl library. Got the following information from gentoolkit's euse utility:

Code: Select all

# euse -i debug
debug [-] [ ] [G] Tells configure and the makefiles to build for debugging.
                  Effects vary acrosss packages, but generally it will at
                  least add -g to CFLAGS. Remember to set FEATURES+=nostrip
                  too.

I tried it and it worked thankfully.

[mulicheng]

i don't understand why glibc needs to be compiled with debug info. why would that affect gdb's thread debugging capabilities? was this an issue with the older linuxthreads?

This was not an issue with the older linuxthreads. I was able to debug the same program on a different system without a debug build of glibc. I'm not sure why the debug build is now needed, but I, like you, would rather not have to build glibc with debug mode.

i dont like the idea of running glibc in debug (wouldn't that potentially slow down the rest of the system)?

I don't think that speed is affected, I'm not a very reliable authority on glibc or anything though. I think it just makes the executable/library sizes a lot bigger like you mentioned.

[lplatypus]

I encountered the same problem. I found that to fix it, I needed only to specify

Code: Select all

FEATURES="nostrip"

there was no need to specify

Code: Select all

USE="debug"

(This is using glibc-2.3.3_pre20040207.ebuild)

[mulicheng]

Yup, I've hence found that same thing, there is no need to compile in debug mode. It is the nostrip FEATURE that fixes this issue.

[pelckyboy]

Works like a charm !!! only the FEATURES="nostrip" is necessary. Thanks so much for the info !!! I'm looking for months now why my gdb was not working with threads... Shouldn't someone enter a bug in bugzilla so this issue is resolved ?

[luked]

Shouldn't someone enter a bug in bugzilla so this issue is resolved ?

I already have: http://bugs.gentoo.org/show_bug.cgi?id=46186

[Cicero]

The only file that shouldn't be stripped is libpthread. If you want a slim glibc, you can compile it unstripped, copy libpthread somewhere, rebuild glibc normally, and then copy libpthread back.