From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14736 invoked by alias); 2 Oct 2007 19:15:51 -0000 Received: (qmail 14724 invoked by uid 22791); 2 Oct 2007 19:15:50 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 02 Oct 2007 19:15:47 +0000 Received: (qmail 18263 invoked from network); 2 Oct 2007 19:15:45 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 2 Oct 2007 19:15:45 -0000 To: Carlos Eduardo Seo Cc: gdb@sourceware.org, drow@false.org, vladimir@codesourcery.com Subject: Re: DWARF question References: <46FAC9D7.9080001@linux.vnet.ibm.com> <20070926212539.GA17502@caradoc.them.org> <46FAD46B.9000006@br.ibm.com> <46FD5A9B.2070004@linux.vnet.ibm.com> <46FD7AE9.8030208@linux.vnet.ibm.com> <4701333C.9040705@linux.vnet.ibm.com> From: Jim Blandy Date: Tue, 02 Oct 2007 19:15:00 -0000 In-Reply-To: <4701333C.9040705@linux.vnet.ibm.com> (Carlos Eduardo Seo's message of "Mon, 01 Oct 2007 14:49:48 -0300") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00017.txt.bz2 Carlos Eduardo Seo writes: > Jim Blandy wrote: >> >> What probably happens is that '-readnow' somehow affects the order in >> which the full symtabs get put in the list. I'm surprised that >> breakpoints by line number in both main and the function work, but I >> guess that has something to do with the nature of the bug in >> find_line_symtab. > Here's what I got. The loop 'ALL_SYMTABS' has only one iteration > because 's->next' is NULL. So it seems that GDB isn't loading the > other symtab. > > When I use '-readnow', both symtabs are there: > > (top-gdb) p s->filename > $6 = 0x106a4930 "init.c" > (top-gdb) p (s->next)->filename > $7 = 0x1069cf10 "/usr/src/packages/BUILD/glibc-2.4/cc-nptl/csu/crti.S" > (top-gdb) p ((s->next)->next)->filename > $8 = 0x1069cc60 "test-main.f" > (top-gdb) p (((s->next)->next)->next)->filename > $9 = 0x1069c280 "test-main.f" > (top-gdb) p ((((s->next)->next)->next)->next)->filename > $10 = 0x1068d5c0 "crtsavres.S" > (top-gdb) p (((((s->next)->next)->next)->next)->next)->filename > $11 = 0x1068d2a0 "/usr/src/packages/BUILD/glibc-2.4/cc-nptl/csu/crtn.S" > (top-gdb) p (((((s->next)->next)->next)->next)->next)->next > $17 = (struct symtab *) 0x0 > > And the loop 'ALL_SYMTABS' work. So, it looks like the bug isn't in > this function. I'm going to look at where GDB populates the symtabs > list now. > > Any thoughts? (Vlad, this touches on some of the multi-breakpoint code. If you're interested, I'm using example code I posted up-thread.) I think I see the problem. First, check this out: (gdb) break 20 No line 20 in file "1s2c.c". (gdb) break 10 Breakpoint 1 at 0x80483a1: file 1s2c.c, line 10. (gdb) break 20 Breakpoint 2 at 0x80483c6: file 1s2c.c, line 20. (gdb) So, for some reason setting a breakpoint on line 10 reads in both symtabs, but setting one in line 20 does not. What's going on is as follows: When we type 'break 20', GDB needs to know what source file we're referring to. select_source_symtab says: /* Make the default place to list be the function `main' if one exists. */ if (lookup_symbol (main_name (), 0, VAR_DOMAIN, 0, NULL)) ... So this brings in full symbols for whatever compilation unit contains 'main'. However, that symtab doesn't have a line 20, so the command fails. When we type 'break 10', main's symtab does have a line 10, so we succeed. However, we then call expand_line_sal (added as part of Vlad's new multi-location breakpoint code), which reads in full symbols for all partial symbol tables with the given name --- including the one that does have a line 20. Thus, when we type 'break 20' the second time, the loop in find_line_symtab does have a second symtab to search, and the search succeeds. As for the fix, it seems to me that if find_line_symtab can't find a match in the symtabs currently loaded, it should expand partial symbol tables with the same name as the given symtab one by one until it either finds one that does have the line we're looking for, or it runs out of plausible psymtabs to try. Even when find_line_common does return a line number, if it sets *exact_match is zero, I think find_line_symtab should proceed to expand psymtabs. Otherwise, if the first symtab we happen to find has line numbers higher than the one we're looking for, but some unread symtab has an exact match, we'll just return the first line number in the symtab we've got.