Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [RFA] Testcase for backtrace/1435
@ 2003-11-17 21:40 Mark Kettenis
  2003-11-17 23:38 ` Daniel Jacobowitz
  2003-11-21 17:51 ` David Carlton
  0 siblings, 2 replies; 6+ messages in thread
From: Mark Kettenis @ 2003-11-17 21:40 UTC (permalink / raw)
  To: gdb-patches

This adds a testcase for the patch I just submitted.  This is
i386-specific, but I don't know how to trick GCC into putting two
functions right after oneother without using assembler.

OK to check this in?

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* gdb.arch/i386-unwind.exp: New file.
	* gdb.arch/i386-unwind.c: New file.

Index: gdb.arch/i386-unwind.exp
===================================================================
RCS file: gdb.arch/i386-unwind.exp
diff -N gdb.arch/i386-unwind.exp
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ gdb.arch/i386-unwind.exp 17 Nov 2003 21:38:21 -0000
@@ -0,0 +1,63 @@
+# Copyright 2003 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+# Please email any bugs, comments, and/or additions to this file to:
+# bug-gdb@gnu.org
+
+# This file is part of the gdb testsuite.
+
+if $tracelevel {
+    strace $tracelevel
+}
+
+# Test i386 unwinder.
+
+set prms_id 0
+set bug_id 0
+
+if ![istarget "i?86-*-*"] then {
+    verbose "Skipping i386 unwinder tests."
+    return
+}
+
+set testfile "i386-unwind"
+set srcfile ${testfile}.c
+set binfile ${objdir}/${subdir}/${testfile}
+if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
+    gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
+}
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+gdb_load ${binfile}
+
+#
+# Run to `main' where we begin our tests.
+#
+
+if ![runto_main] then {
+    gdb_suppress_tests
+}
+
+# Testcase for backtrace/1435.
+
+gdb_test "continue" "Program received signal SIGTRAP.*" \
+         "continue past gdb1435"
+
+gdb_test "backtrace 10" \
+	"#1\[ \t]*$hex in gdb1435.*\r\n#2\[ \t\]*$hex in main.*" \
+	"backtrace past gdb1435"
Index: gdb.arch/i386-unwind.c
===================================================================
RCS file: gdb.arch/i386-unwind.c
diff -N gdb.arch/i386-unwind.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ gdb.arch/i386-unwind.c 17 Nov 2003 21:38:21 -0000
@@ -0,0 +1,42 @@
+/* Unwinder test program.
+
+   Copyright 2003 Free Software Foundation, Inc.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+   
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+   
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330,
+   Boston, MA 02111-1307, USA.  */
+
+void
+trap (void)
+{
+  asm ("int $0x03");
+}
+
+/* Make sure that main directly follows a function without an
+   epilogue.  */
+
+asm(".text\n"
+    "    .align 8\n"
+    "    .globl gdb1435\n"
+    "gdb1435:\n"
+    "    pushl %ebp\n"
+    "    mov   %esp, %ebp\n"
+    "    call  trap\n"
+    "    .globl main\n"
+    "main:\n"
+    "    pushl %ebp\n"
+    "    mov   %esp, %ebp\n"
+    "    call  gdb1435\n");


^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [RFA] Testcase for backtrace/1435
@ 2003-11-22 20:17 Michael Elizabeth Chastain
  2003-11-23 20:21 ` Mark Kettenis
  0 siblings, 1 reply; 6+ messages in thread
From: Michael Elizabeth Chastain @ 2003-11-22 20:17 UTC (permalink / raw)
  To: carlton, kettenis; +Cc: gdb-patches

I see the same FAIL that David Carlton is seeing.  This happens with
dwarf-2 on all my versions of gcc and binutils.  It doesn't happen
with stabs+.

The problem is with the dwarf-2 line table.  Look at this gdb output:

  (gdb) print &main
  $1 = (<text variable, no debug info> *) 0x8048358 <main>

  (gdb) break main
  Breakpoint 1 at 0x804834c: file /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.arch/i386-unwind.c, line 26.

0x804834c is a lot different from 0x8048358!

The source code is:

  trap () { ... }
  asm ( ... "gdb1435" ... )
  asm ( ... "main" ... )

And the addresses in the executable file are:

  (gdb) disass trap
  Dump of assembler code for function trap:
  0x08048348 <trap+0>:    push   %ebp
  0x08048349 <trap+1>:    mov    %esp,%ebp
  0x0804834b <trap+3>:    int3
  0x0804834c <trap+4>:    pop    %ebp
  0x0804834d <trap+5>:    ret
  End of assembler dump.

  (gdb) disass gdb1435
  Dump of assembler code for function gdb1435:
  0x08048350 <gdb1435+0>: push   %ebp
  0x08048351 <gdb1435+1>: mov    %esp,%ebp
  0x08048353 <gdb1435+3>: call   0x8048348 <trap>
  End of assembler dump.

  (gdb) disass main
  Dump of assembler code for function main:
  0x08048358 <main+0>:    push   %ebp
  0x08048359 <main+1>:    mov    %esp,%ebp
  0x0804835b <main+3>:    call   0x8048350 <gdb1435>
  End of assembler dump.

In the source code, line 26 is the closing brace of the "trap" function.
All the assembly code after that gets associated with this line!
"break main" calls find_pc_sect_line to map the address of "main"
onto a line number, comes up with 26, and sets the breakpoint on line 26.

I watched this happening by stepping through find_pc_sect_line.

"readelf -wl i386-unwind" gives this line table:

 Line Number Statements:
  Extended opcode 2: set Address to 0x8048348
  Advance Line by 23 to 24
  Copy
  Special opcode 48: advance Address by 3 to 0x804834b and Line by 1 to 25
  Special opcode 20: advance Address by 1 to 0x804834c and Line by 1 to 26
  Advance PC by 20 to 8048360
  Extended opcode 1: End of Sequence

In contrast, when I compile with -gstabs+ rather than -gdwarf-2, the
line table entry for line 26 ends at the end of the "trap" function like
it's supposed to.  find_pc_sect_line sees that the pc for "main" is not
associated with any line and does not adjust it to the beginning of the
line.

This is a bug somewhere, but I don't know where:

  It could be a bug in the test program i386-unwind.c.  There's not
  really a spec for how to write mixed C / assembly and have debugging
  work.  But i386-unwind.c is not that tricky.

  It could be a bug in the gcc dwarf-2 writer.  Look at the output
  of "readelf -wl" and ask yourself if "Advance PC by 20 to 8048360"
  is correct.

  Or it could be a bug in gdb.  I doubt this, because I bet that gdb
  is just reading the line table that it's given.

I am going to file a gdb PR.  If we decide that there is a gcc bug then
we can file a gcc PR.  And, we can either change the test script or
KFAIL this test.

dc> (though the tests themselves still execute and pass,
dc> which I don't quite understand).

Well, the test script wants to do "break main; run" to get to "main"
and then "continue" to get to the "int $3" instruction.  Instead,
"break main" gets set right after the "int $3", and then "run"
runs all the way to the "int $3".  Then the "continue" hits the
same SIGTRAP again.  It's really co-incidental that the target
program ends up at or near the right $PC.

Michael C


^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [RFA] Testcase for backtrace/1435
@ 2003-11-23 21:57 Michael Elizabeth Chastain
  0 siblings, 0 replies; 6+ messages in thread
From: Michael Elizabeth Chastain @ 2003-11-23 21:57 UTC (permalink / raw)
  To: kettenis; +Cc: carlton, gdb-patches

I'm not sure if the symtab problem is a gdb problem, a gcc problem,
or just a problem with the way the source file was written.

So I'll just leave the PR open and someone can work on it in the future.

Michael C


^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-11-23 21:57 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-17 21:40 [RFA] Testcase for backtrace/1435 Mark Kettenis
2003-11-17 23:38 ` Daniel Jacobowitz
2003-11-21 17:51 ` David Carlton
2003-11-22 20:17 Michael Elizabeth Chastain
2003-11-23 20:21 ` Mark Kettenis
2003-11-23 21:57 Michael Elizabeth Chastain

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox