From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2042 invoked by alias); 22 Nov 2003 20:17:37 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2034 invoked from network); 22 Nov 2003 20:17:37 -0000 Received: from unknown (HELO barry.mail.mindspring.net) (207.69.200.25) by sources.redhat.com with SMTP; 22 Nov 2003 20:17:37 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1ANeCD-0004Nr-00; Sat, 22 Nov 2003 15:17:33 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id 404C84B36E; Sat, 22 Nov 2003 15:17:32 -0500 (EST) To: carlton@kealia.com, kettenis@chello.nl Subject: Re: [RFA] Testcase for backtrace/1435 Cc: gdb-patches@sources.redhat.com Message-Id: <20031122201732.404C84B36E@berman.michael-chastain.com> Date: Sat, 22 Nov 2003 20:17:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2003-11/txt/msg00469.txt.bz2 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 = ( *) 0x8048358
(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 : push %ebp 0x08048349 : mov %esp,%ebp 0x0804834b : int3 0x0804834c : pop %ebp 0x0804834d : ret End of assembler dump. (gdb) disass gdb1435 Dump of assembler code for function gdb1435: 0x08048350 : push %ebp 0x08048351 : mov %esp,%ebp 0x08048353 : call 0x8048348 End of assembler dump. (gdb) disass main Dump of assembler code for function main: 0x08048358 : push %ebp 0x08048359 : mov %esp,%ebp 0x0804835b : call 0x8048350 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