From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13058 invoked by alias); 2 Jan 2004 14:18:05 -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 13051 invoked from network); 2 Jan 2004 14:18:03 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 2 Jan 2004 14:18:03 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AcQ7m-0007RO-W3 for ; Fri, 02 Jan 2004 09:18:02 -0500 Date: Fri, 02 Jan 2004 14:18:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFC/dwarf-2] Add support for included files Message-ID: <20040102141802.GA28372@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20040102072500.GS826@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040102072500.GS826@gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00018.txt.bz2 On Fri, Jan 02, 2004 at 08:25:00AM +0100, Joel Brobecker wrote: > We have noticed that, if compiled with dwarf-2, GDB is unable to > set a breakpoint inside hello.c using the file:lineno syntax: > > % gcc -gdwarf-2 foo.c -o foo > % gdb foo > (gdb) b hello.c:4 > No source file named hello.c. > (gdb) list hello.c:4 > No source file named hello.c. > > However, we can set the breakpoint using the function name: > > (gdb) b say_hello > Breakpoint 1 at 0x804833e: file hello.c, line 4. > > And then once this breakpoint is set, we can now insert the > breakpoint using the source location: > > (gdb) b hello.c:4 > Note: breakpoint 1 also set at pc 0x804833e. > Breakpoint 2 at 0x804833e: file hello.c, line 4. > (gdb) list hello.c:4 > 1 void > 2 say_hello (void) > 3 { > 4 printf ("Hello world.\n"); > 5 } Yes... I've noticed this several times recently. > In Dwarf-2, the list of included files is linked to the line table. > First, we have "Line Number Program Header" which contains the "file > names" table. And then the program itself which uses the DW_LNS_set_file > opcode to change from file to file. There is also the DW_LNE_defile_file > opcode that can be used to define new files instead of using the "file > names" table. You keep saying that. I don't think it means what you think it means :) (Hint: DW_LNE_define_file, not DW_LNE_defile_file.) > Basically, I just copy/pasted the code from dwarf_decode_lines(), > simplified it for partial symtab processing, and then called it > right after the compilation unit psymtab has been built. Currently, > the function scans the line number program, and records which files > of the "file names" table have really been included in the line program > (that's the "file_included" array). > > Here is a patch against GDB 6.0 that I used as a proof of concept. > It does not handle the case where the compiler uses DW_LNE_defile_file > instead of the the "file names" table yet, but that will be taken care > of. Would that be an acceptable approach to suggest for inclusion? Well, the question is whether this works well enough. Things _are_ in these files - DW_AT_decl_file points to them. Do we need to also put things into the proper psymtabs? Otherwise the approach seems reasonable. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer