From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6630 invoked by alias); 26 Jul 2007 22:30:31 -0000 Received: (qmail 6623 invoked by uid 22791); 26 Jul 2007 22:30:31 -0000 X-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,SARE_MLB_Stock5,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Jul 2007 22:30:24 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l6QMUMxa001798 for ; Thu, 26 Jul 2007 18:30:22 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l6QMUMgG025172; Thu, 26 Jul 2007 18:30:22 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l6QMUKIe004517; Thu, 26 Jul 2007 18:30:21 -0400 Message-ID: <46A9209F.30103@redhat.com> Date: Thu, 26 Jul 2007 22:30:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Roland McGrath CC: frysk@sourceware.org Subject: Re: which elf symbol? References: <20070726022738.4350E4D058D@magilla.localdomain> In-Reply-To: <20070726022738.4350E4D058D@magilla.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q3/txt/msg00205.txt.bz2 Roland McGrath wrote: > I reduced your report to an isolated test case of trivial assembly. I've > slightly modified addr2line so I'm using it as a test program with -e on > the .o file to just print out the results of dwfl_module_addrsym. > Please help me adjust this test case to match (or also include) cases > equivalent to what you are seeing. > What about a case like: symbol: nop unsized_symbol: nop .size symbol, .-symbol 1: the closest symbol is unsized_symbol, but that is probably not the intent. > >> local_st_size_0: // this symbol has no size >> >> global_outer: >> nop >> local_in_global: >> nop >> .size local_in_global, .-local_in_global >> nop >> <> >> .size global_outer, .-global_outer >> >> that is global_outer contains a nested symbol but the "pc" is beyond >> that back in the outer/global symbol. >> >> I'm guessing that "global_outer" should be returned. Currently >> local_st_size_0 is returned :-( >> > > Arguably the answer should be no symbol, since the address is past the end > of the nearest symbol's size. > the xample was unclear <> is ment to be within global_outer; your test did that. > This is t1 in my test case, looking at pc=0x2. I get t1_global_outer+0x2 > from addrsym here, so my case must differ from what you tried here. > Can you figure out how they differ? > > I'm looking. >> This is the no-symbol case, there is a hole in the memory where there is >> no valid symbol vis: >> >> local_st_size_0: // this symbol has no size >> >> global_symbol: >> nop >> nop >> .size global_symbol, .-global_symbol >> >> << you are here >> >> >> I'm guessing it should not get a symbol at all (the [unknown]). It >> currently gets the nearest unsized symbol. >> > > This is t2 in my test case, looking at pc=0x6a. > I get t2_local_st_size_0+0x2 here. Go figure. > > You wrote your marker in a different place, but there is no address > difference between the context before the .size directive in the assembly > source and the context after it. So unless I'm misunderstanding what cases > you intended to describe, this should be the same case as t1. (It doesn't > really matter that there is a local symbol nearby, since the PC of interest > is unambiguous outside that symbol's address range.) > > I'll look into why they come out differently, which might relate to some > other symptom. I also agree that the right answer is no symbol. > > ok. >> These are cases where there is a nested symbol within a sized symbol vis: >> >> global_after_0: >> nop >> local_0_in_global: >> << you are here >> >> nop >> .size global_after_0, .-global_after_0 >> >> here, since the PC is exactly at the unsized local symbol I'm guessing >> that it should return that. It currently gets the containing sized symbol. >> > > This is my t3. I get t3_global_after_0+0x1 as you say. This is the > intended behavior, not a bug. We can discuss what the behavior should be. > > /* Handwritten assembly symbols sometimes have no st_size. > If no symbol with proper size includes the address, we'll > use the closest one that is in the same section as ADDR. */ > > Yes, agreed. The sized symbol should trump the unsized one. > Usually size-0 symbols are local assembler labels, and sized symbols are > the entry points. For things like backtraces, people usually want to see > the symbol names for the entry points (plus offsets) rather than the local > labels that often have unhelpful names. That's what I had in mind when I > wrote that. addrsym started out as addrname, which does not pass back an > offset and only used for "what function is this in?" kinds of queries. For > that, it clearly makes more sense to prefer the containing sized symbol. > > However, for things like disassembly, people probably would like to see the > local label names, or perhaps both names. > > That's an interesting option; it would better reflect exactly what is in the file. Andrew > Thanks, > Roland >