Since the 6.8 releases, gdb totally fails to detect stack frames correctly, whereas the lenny version (6.7.1-2 atm) works fine. My architecture is amd64, but I've seen the same issues on i386 FWIW. The code is C, with quite a few inlines, changing the gcc debug levels (-g/-g3/-ggdb3) or even building with -O0 -fno-inline doesn't change a damn thing. This renders gdb mostly unusable because it's totally unable to dump useful backtraces (with source files and files lineno's) on segfaults.
severity 485955 normal thanks I've seen no evidence this bug affects anyone else and the package is clearly not unusable. Downgrading. Can you provide a test case? Or even an example session? I can't read your mind...
(gdb) bt #0 sms_emi_ack_5X (out=0x1b1dc88, msg=0x7fff637d97e0) at lib-inet/sms-emi.c:230 #1 0x0000000000404973 in ?? () #2 0x00000000004182f7 in ?? () #3 0x0000000000412400 in sms_parse_emi (in=0x1b1dc70, out=0x1b1dc88, on_msg=<value optimized out>, priv=<value optimized out>) at lib-inet/sms-emi-parse.c:752 #4 0x0000000000418f25 in ?? () #5 0x0000000000406850 in agent_dispatch_epoll (timeout=<value optimized out>) at lib-inet/agent.c:1076 #6 0x0000000000403a2f in main (argc=<value optimized out>, argv=<value optimized out>) at simulator/smsc/smsc.c:90 With gdb from etch: (gdb) bt #0 sms_emi_ack_5X (out=0x110dc88, msg=0x7fff73230240) at lib-inet/sms-emi.c:230 #1 0x0000000000404973 in smsc_emi_on_query (we=0x110dbe0, msg=0x7fff73230240) at simulator/smsc/emi_smsc.c:232 #2 0x00000000004182f7 in emi_common_hook (msg=0x7fff73230240, _w=<value optimized out>) at lib-inet/smsmachines.c:269 #3 0x0000000000412400 in sms_parse_emi (in=0x110dc70, out=0x110dc88, on_msg=<value optimized out>, priv=<value optimized out>) at lib-inet/sms-emi-parse.c:752 #4 0x0000000000418f25 in emilistener_event (w=0x110a0a0, kind=<value optimized out>) at lib-inet/smsmachines.c:379 #5 0x0000000000406850 in agent_dispatch_epoll (timeout=<value optimized out>) at lib-inet/agent.c:1076 #6 0x0000000000403a2f in main (argc=<value optimized out>, argv=<value optimized out>) at simulator/smsc/smsc.c:90 I here just ran gdb ./myexe and placed a breakpoint on sms_emi_ack_5X. It seems there is something fishy with pointer to functions as emilistener_event emi_common_hook and smsc_emi_on_query are callbacks. I'm sorry but I just can't give you access to that code :/ -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Note, same address. Is a shared library involved? Does "list smsc_emi_on_query" do anything?
No, the symbol is local, visibility hidden.
lenny:
(gdb) list smsc_emi_on_query
249 {
[... dumps code ...]
(gdb) b smsc_emi_on_query
Breakpoint 1 at 0x404520: file simulator/smsc/emi_smsc.c, line 254.
sid:
(gdb) list smsc_emi_on_query
No line number known for smsc_emi_on_query.
(gdb) b smsc_emi_on_query
Breakpoint 1 at 0x404520
./gdb ~/dev/mmsx/simulator/smsc/smsc
GNU gdb 6.8-debian
[...]
This GDB was configured as "x86_64-linux-gnu"...
Setting up the environment for debugging gdb.
Function "internal_error" not defined.
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
Function "info_command" not defined.
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
/home/madcoder/debian/tmp/gdb-6.8/objdir/gdb/.gdbinit:8: Error in sourced command file:
No breakpoint number 0.
(gdb) b smsc_emi_on_query
During symbol reading, DW_AT_name missing from DW_TAG_base_type.
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
Breakpoint 1 at 0x404520
(gdb)
Which I can reproduce doing that on the sid one:
(gdb) set complaints 1
(gdb) b smsc_emi_on_query
During symbol reading, DW_AT_name missing from DW_TAG_base_type.
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
Breakpoint 1 at 0x404520
But not completely from the lenny one:
(gdb) set complaints 1
(gdb) b smsc_emi_on_query
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
Breakpoint 1 at 0x404520: file simulator/smsc/emi_smsc.c, line 254.
Also, the testsuite is still running but I already saw those failures:
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.base/break.exp ...
FAIL: gdb.base/break.exp: breakpoint at start of multi line while conditional
FAIL: gdb.base/break.exp: breakpoint info
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.base/corefile.exp ...
FAIL: gdb.base/corefile.exp: accessing mmapped data in core file (mapping address not found in core file)
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.base/mips_pro.exp ...
FAIL: gdb.base/mips_pro.exp: running to middle in runto
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.base/sepdebug.exp ...
FAIL: gdb.base/sepdebug.exp: breakpoint at start of multi line while conditional
FAIL: gdb.base/sepdebug.exp: breakpoint info
Running /home/madcoder/debian/tmp/gdb-6.8/gdb/testsuite/gdb.cp/annota3.exp ...
FAIL: gdb.cp/annota3.exp: annotate-quit (pattern 1)
The debug readers were not able to parse this function's debug info. Is there any chance you can reproduce this with a smaller piece of code that you can share? I don't need source, just linked executable.
Attached is the full suite log. Tell me if you want/need anything else.
These complaints are not relevant to your error. See the log in /usr/share/doc/gdb for typical failures. Does readelf -wi complain about the file containing one of your 'invisible' functions? What does the DW_TAG_subprogram look like for smsc_emi_on_query?
Here is the diff:
@@ -107,2 +106,4 @@
Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.base/break.exp ...
+FAIL: gdb.base/break.exp: breakpoint at start of multi line while conditional
+FAIL: gdb.base/break.exp: breakpoint info
Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.base/call-ar-st.exp ...
@@ -177,2 +178,3 @@
Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.base/mips_pro.exp ...
+FAIL: gdb.base/mips_pro.exp: running to middle in runto
Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.base/miscexprs.exp ...
@@ -212,2 +214,4 @@
Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.base/sepdebug.exp ...
+FAIL: gdb.base/sepdebug.exp: breakpoint at start of multi line while conditional
+FAIL: gdb.base/sepdebug.exp: breakpoint info
Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.base/sepsymtab.exp ...
@@ -259,5 +263,5 @@
Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.cp/annota3.exp ...
+FAIL: gdb.cp/annota3.exp: annotate-quit (pattern 1)
Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.cp/anon-union.exp ...
Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.cp/arg-reference.exp ...
-FAIL: gdb.cp/arg-reference.exp: No false reference
Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.cp/bool.exp ...
@@ -281,3 +285,4 @@
FAIL: gdb.cp/inherit.exp: ptype tagless struct
-FAIL: gdb.cp/inherit.exp: print type of anonymous union // unrecognized line type 1: class_with_anon_union::._0;
+FAIL: gdb.cp/inherit.exp: ptype variable of type tagless struct
+FAIL: gdb.cp/inherit.exp: print type of anonymous union // unrecognized line type 1: class_with_anon_union::<anonymous union>;
Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.cp/local.exp ...
@@ -475,2 +478,3 @@
Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.threads/thread_check.exp ...
+FAIL: gdb.threads/thread_check.exp: breakpoint at tf
Running /tmp/buildd/gdb-6.8/gdb/testsuite/gdb.threads/thread_events.exp ...
I see nothing special no.
<1><6274>: Abbrev Number: 71 (DW_TAG_subprogram)
<6275> DW_AT_name : (indirect string, offset: 0x1ce4): smsc_emi_on_query
<6279> DW_AT_decl_file : 1
<627a> DW_AT_decl_line : 254
<627b> DW_AT_prototyped : 1
<627c> DW_AT_type : <33fa>
<6280> DW_AT_low_pc : 0x404520
<6288> DW_AT_high_pc : 0x404d21
<6290> DW_AT_frame_base : 0xcc8 (location list)
<6294> DW_AT_sibling : <644d>
See your query on IRC for the rest.
Normally, when this happens, there is a symbol in the ELF symbol table (.symtab) for the hidden symbol. That symbol is missing in your case. I don't know why it worked pre-6.7, but this is not a well-supported case in GDB. It expects there to be ELF symbols for all functions. Fortunately, an optimized code improvement added to GDB HEAD after 6.8 fixes your testcase again. In the mean time, I suggest you use 6.7, use HEAD, or arrange not to strip a subset of ELF symbols.
Well I really don't do anything fancy here, no linker script is involved, just simple gcc… okay, I'm glad then. That's what I'm doing (the former) for now. Thanks
Could this be the same bug as: https://bugzilla.novell.com/show_bug.cgi?id=390722 and https://bugs.launchpad.net/ubuntu/hardy/+source/gdb/+bug/111869 ? (with patch available) James
No, it's not related.