Hi, Since fairly recently, gdb on powerpc in sid misbehaves when a function call to a shared library is being executed. Rather than just stepping into the function (or skipping it if 'next' is being used), gdb first steps into a function called 'call___do_global_ctors_aux()'. After going through this function, a number of things may happen: in some cases it jumps to yet another function before actually going through the function that has been requested; after that, the request to skip over the actual function when 'next' has been used may or may not be totally ignored. In some cases even the return from the function call is not caught anymore, so that the program simply continues running from that point on, rather than allowing me to step through the code. This makes properly debugging programs rather hard.
Could you show me the output of such a session, please?
Hi, I apparently missed your request for the output of such a session somehow. Attached is a typescript. You won't see it totally missing out on the function call return, since I couldn't reproduce that at this point (and I couldn't remember a case where it happened). I have no reason to believe, however, that this behaviour has gone away. This is an optimized binary; but it happens with software compiled with -O0, too. If you need me to do anything else, just let me know.
session Breakpoint 1, main (argc=4, argv=0x7ff87624) at test-photos.c:384 384 if (argc < 2) (gdb) n 390 setlocale (LC_ALL, ""); (gdb) 0x10003610 in call___do_global_ctors_aux () (gdb) Single stepping until exit from function call___do_global_ctors_aux, which has no line number information. 0x0ffd4cc4 in ?? () from /lib/ld.so.1 (gdb) Cannot find bounds of current function (gdb) Cannot find bounds of current function (gdb) Cannot find bounds of current function (gdb) I am available for further testing/experimenting filippo -- Filippo Giunchedi - http://esaurito.net PGP key: 0x6B79D401 random quote follows: I find television very educating. Every time somebody turns on the set, I go into the other room and read a book. -- Groucho Marx
Not from me, but I think Ulrich Weigand may have fixed it upstream today. http://sourceware.org/ml/gdb-patches/2007-10/msg00837.html There's no open PowerPC developer system where I can test it, though.
Great. There's bruckner.debian.org... if that isn't sufficient for some reason, I can give you an account on ragtime.nixsys.be -- but note that this is a rather old machine.
Bruckner's unstable chroot has not been updated since mid-2006. Not very unstable of it. I'll just include the patch next time I upload and we'll see if that helps.
Breakpoint 1, main (argc=4, argv=0x7fb8f644) at test-photos.c:384 384 if (argc < 2) (gdb) n 390 setlocale (LC_ALL, ""); (gdb) 391 g_type_init (); (gdb) 393 if (strcmp (argv[1], "dump") == 0) (gdb) 395 return do_dump (argc, argv); (gdb) many thanks! filippo -- Filippo Giunchedi - http://esaurito.net PGP key: 0x6B79D401 random quote follows: Caelum, non animo mutant, qui trans mare currunt Who crosses the sea changes the sky, not the soul. -- Oratius
We believe that the bug you reported is fixed in the latest version of
gdb, which is due to be installed in the Debian FTP archive:
gdb_6.7.1-2.diff.gz
to pool/main/g/gdb/gdb_6.7.1-2.diff.gz
gdb_6.7.1-2.dsc
to pool/main/g/gdb/gdb_6.7.1-2.dsc
gdb_6.7.1-2_amd64.deb
to pool/main/g/gdb/gdb_6.7.1-2_amd64.deb
libgdb-dev_6.7.1-2_amd64.deb
to pool/main/g/gdb/libgdb-dev_6.7.1-2_amd64.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 432461@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Daniel Jacobowitz <dan@debian.org> (supplier of updated gdb package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)
Format: 1.7
Date: Wed, 02 Jan 2008 08:49:43 -0500
Source: gdb
Binary: gdb64 gdb libgdb-dev
Architecture: source amd64
Version: 6.7.1-2
Distribution: unstable
Urgency: low
Maintainer: Daniel Jacobowitz <dan@debian.org>
Changed-By: Daniel Jacobowitz <dan@debian.org>
Description:
gdb - The GNU Debugger
libgdb-dev - The GNU Debugger (libgdb.a)
Closes: 432461 455669 458250
Changes:
gdb (6.7.1-2) unstable; urgency=low
.
* Add patch from Ulrich Weigand to fix stepping over shared library
functions on PowerPC (Closes: #432461).
* Add libgdb-dev package for fp-ide (Closes: #458250).
* Avoid gcc-4.3 uninitialized warnings (Closes: #455669).
* Updated Standards-Version to 3.7.3
- Correct Apps -> Applications in gdb.menu.
Files:
6bb05de7af2bbab1275551923b23714a 1480 devel optional gdb_6.7.1-2.dsc
3183fc47c8b2a1121bcab5d9ce871272 35678 devel optional gdb_6.7.1-2.diff.gz
f33b0926aa7ad100d693aa39bec61233 2932850 devel optional gdb_6.7.1-2_amd64.deb
eda596d3cba188d63345ceb98741c05f 1531864 libdevel extra libgdb-dev_6.7.1-2_amd64.deb
iD8DBQFHfptObgOPXuCjg3cRAq7uAKCK0wwrMssORDdHW52usngn4a7fsACgo1tR
w0FNZYivGGHZS/NIeqoIWFo=
=FFDY
-----END PGP SIGNATURE-----
notfixed 432461 6.7.1-2 thanks I still see the broken behaviour in that version of gdb. I'm not sure what exactly is going on; but my offer for an account on ragtime.nixsys.be still stands.
Hi, I *thought* I'd sent some more information on this bug a while ago, but apparently I didn't. Sorry about that. This bug no longer occurs if you're only trying to debug an application; gdb understands that an application is not a library, and accordingly doesn't attempt to step into a function if the function is a library call. However, once you start stepping into a library (because, say, you're actually developing a library), the distinction between 'application functions' and 'library functions' that gdb uses to distinguish whether or not to step in or over a library call disappears (because every call is a library call, I presume), and the bug reappears.
GDB doesn't differentiate between library and application functions; I assume this is some difference in the PLT sequence between applications and shared libraries that GDB is not prepared for.
The notmuch test suite is currently failing on ppc64el (but not on plain
old ppc) because of what looks like this bug.
% gdb --args ../../notmuch --config=notmuch-config insert
GNU gdb (Debian 7.10-1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "powerpc64le-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../../notmuch...done.
(gdb) set breakpoint pending on
(gdb) break notmuch_database_add_message
Breakpoint 1 at 0x10024fb0: file lib/database.cc, line 2390.
(gdb) run --config=notmuch-config insert < mail/msg-002
Starting program: /home/bremner/notmuch-0.21~rc3/notmuch --config=notmuch-config insert < mail/msg-002
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".
[Inferior 1 (process 10804) exited normally]
(gdb) break notmuch_insert_command
Breakpoint 2 at 0x1000f550: file notmuch-insert.c, line 445.
(gdb) run
Starting program: /home/bremner/notmuch-0.21~rc3/notmuch --config=notmuch-config insert < mail/msg-002
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".
Breakpoint 2, notmuch_insert_command (config=<optimized out>, argc=<optimized out>,
argv=<optimized out>) at notmuch-insert.c:445
445 {
(gdb) break 549
Breakpoint 3 at 0x1000fe44: file notmuch-insert.c, line 549.
(gdb) cont
Continuing.
Breakpoint 3, notmuch_insert_command (config=0x1009e040, argc=<optimized out>,
argv=<optimized out>) at notmuch-insert.c:549
549 status = add_file (notmuch, newpath, tag_ops, synchronize_flags, keep);
(gdb) s
add_file (keep=0, synchronize_flags=1, tag_ops=0x100a7310,
path=0x100cd8e0 "/home/bremner/notmuch-0.21~rc3/test/tmp.T070-insert/mail/new/1445943068.M434795P11340.plummer", notmuch=0x100a76f0) at notmuch-insert.c:386
386 status = notmuch_database_add_message (notmuch, path, &message);
(gdb) s
notmuch_database_add_message (notmuch=0x100a76f0,
filename=0x100cd8e0 "/home/bremner/notmuch-0.21~rc3/test/tmp.T070-insert/mail/new/1445943068.M434795P11340.plummer", message_ret=0x3fffffffddd0)
at lib/database.cc:2401
2401 if (message_ret)
(gdb) bt
#0 notmuch_database_add_message (notmuch=0x100a76f0,
filename=0x100cd8e0 "/home/bremner/notmuch-0.21~rc3/test/tmp.T070-insert/mail/new/1445943068.M434795P11340.plummer", message_ret=0x3fffffffddd0)
at lib/database.cc:2401
#1 0x000000001000fe5c in add_file (keep=0, synchronize_flags=1,
tag_ops=0x100a7310,
path=0x100cd8e0 "/home/bremner/notmuch-0.21~rc3/test/tmp.T070-insert/mail/new/1445943068.M434795P11340.plummer", notmuch=0x100a76f0) at notmuch-insert.c:386
#2 notmuch_insert_command (config=<optimized out>, argc=<optimized out>,
argv=<optimized out>) at notmuch-insert.c:549
#3 0x000000001000a014 in main (argc=<optimized out>, argv=0x3ffffffff528)
at notmuch.c:421