From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 342 invoked by alias); 18 Nov 2003 01:33:50 -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 335 invoked from network); 18 Nov 2003 01:33:49 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 18 Nov 2003 01:33:49 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1ALukX-0005Fe-1n for ; Mon, 17 Nov 2003 20:33:49 -0500 Date: Tue, 18 Nov 2003 01:33:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFC] minimal symbols on mips-irix and overlapping CUs... Message-ID: <20031118013349.GA20132@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20031117223925.GA8608@gnat.com> <20031117233542.GA12125@nevyn.them.org> <20031118012419.GC8608@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031118012419.GC8608@gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-11/txt/msg00376.txt.bz2 On Mon, Nov 17, 2003 at 05:24:19PM -0800, Joel Brobecker wrote: > > > b. A recent version of the IRIX linker has introduced an extra asm CU > > > (Compilation Unit) named "__sgi_ld_generated_code" which contains > > > one function before CU gdb_local_symbol.adb, and 2 after. So the > > > code range of gdb_local_symbol.adb is included in the code range > > > of the linker CU. > > > > What information does this have - does it have dwarf information or how > > else are we finding its code range? > > This is coming from the dwarf-2 data. The code range is deduced from > the first function start address and the last function end address > (no low_pc and high_pc attributes). OK, makes sense. One thing that would solve your problem, then, would be to record accurate ranges for psymtabs and symtabs. This has been discussed before but never implemented. It may be the best solution. > > Rather than mesing with the minimal symbol table, we should probably be > > correcting the assumption. > > > > Partial symbol tables include function addresses. find_pc_sect_psymtab > > assumes that everything would have a minimal symbol, but we can > > probably correct that. > > The problem I have at the moment is that I don't see how to correct it > reliably. > > > The loop in that function looks quite strange > > to me: note that the inner loop uses the same variable, deliberately, > > as the outer loop. Here's a better version of (b): > > > > > b. Then, we scan all the partial symtabs for the ones which code > > > range include the given address. For all the qualifying ones, > > > we check whether it contains a function which start address > > > matches the minimal symbol address. If yes, then we have found > > > the right symtab. Otherwise, we just return the first partial > > > symtab we found. > > ^^^^^^^^^^^^^^ > > best match > > Suppose you are indeed in a unit for which no debugging information has > been generated. In that case, we should not use any partial symtab, > but the minimal symbol right? How can we be sure of which approach > (debug info vs symbol table) to take without making a gamble? But at present, we might still use the preceding psymtab, wouldn't we? > Hmmm, but maybe I am slightly misunderstanding you: Are you suggesting > that, by returning the best match, the situation will improve, even > if not perfect? Would the best-match comparison use the "distance" > algorithm I have seen somewhere else? (we try to return the smallest > psymtab that contain the address). Similar, see below: the closes psymbol base address less than the address. > > There's already code in find_pc_sect_psymbol to do this sort of > > best-match. Something similar is needed here, but we need to be > > careful of the recursion. Probably, find_pc_sect_psymtab should build > > on find_pc_sect_psymtab rather than the other way around to solve your > > problem. > > Did you mean "Probably, find_pc_sect_psymtab should build on > find_pc_sect_symtab" (typo in second function name?). There is something > I am missing because I thought that the symtab list is not necessarily > compleite, as some psymtabs may not have been converted yet at the time > of the symtab scan. Which to me explained why we relied to the psymtabs > to find the appropriate symtab rather than the other way around... The typo was in the second function, but I meant "find_pc_sect_psymbol". With that does it make more sense? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer