From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15281 invoked by alias); 7 Aug 2007 07:52:57 -0000 Received: (qmail 15259 invoked by uid 22791); 7 Aug 2007 07:52:55 -0000 X-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from rwcrmhc11.comcast.net (HELO rwcrmhc11.comcast.net) (204.127.192.81) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 07 Aug 2007 07:52:51 +0000 Received: from gateway.sf.frob.com (c-67-160-211-197.hsd1.ca.comcast.net[67.160.211.197]) by comcast.net (rwcrmhc11) with ESMTP id <20070807075249m1100116t5e>; Tue, 7 Aug 2007 07:52:49 +0000 Received: from magilla.localdomain (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 76702357B; Tue, 7 Aug 2007 00:52:48 -0700 (PDT) Received: by magilla.localdomain (Postfix, from userid 5281) id 471754D04C4; Tue, 7 Aug 2007 00:52:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Andrew Cagney Cc: frysk@sourceware.org Subject: Re: which elf symbol? In-Reply-To: Andrew Cagney's message of Thursday, 26 July 2007 18:30:55 -0400 <46A9209F.30103@redhat.com> Emacs: don't cry -- it won't help. Message-Id: <20070807075248.471754D04C4@magilla.localdomain> Date: Tue, 07 Aug 2007 07:52:00 -0000 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/msg00272.txt.bz2 > 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. Agreed. I think the correct answer for 1: here is no symbol. Below, this is case t4. > Yes, agreed. The sized symbol should trump the unsized one. Based on what you've said I'm now looking at the following test cases. For me, the current code gets all of these right except t4. I had the impression you had other cases where the current code yields the wrong answer. Please send me an assembly fragment in this style (e.g. t5, t6) on which you've verified addrsym yields the wrong answer, or let me know if cases like t4 are in fact the only specific known bug. I'd like to get these test cases firmly established ASAP, and before considering additional facilities with different behavior as for disassembly. Thanks, Roland .globl t1_global_outer t1_local_st_size_0: t1_global_outer: nop t1_local_in_global: nop .size t1_local_in_global, .-t1_local_in_global 1: nop # the right answer is t1_global_outer .size t1_global_outer, .-t1_global_outer .space 0x100 .balign 8 .globl t2_global_symbol t2_local_st_size_0: t2_global_symbol: nop nop 2: # the right answer is t2_global_symbol nop .size t2_global_symbol, .-t2_global_symbol .space 0x100 .balign 8 .globl t3_global_after_0 t3_global_after_0: nop t3_local_0_in_global: 3: # the right answer is t3_global_after_0 nop .size t3_global_after_0, .-t3_global_after_0 .space 0x100 .balign 8 .globl t4_global t4_global: nop t4_local_0_in_global: nop .size t4_global, .-t4_global 4: nop # the right answer is no answer nop .data t1_pc_of_interest: .long 1b t2_pc_of_interest: .long 2b t3_pc_of_interest: .long 3b t4_pc_of_interest: .long 4b