From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17214 invoked by alias); 31 Jan 2014 16:21:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 17200 invoked by uid 89); 31 Jan 2014 16:21:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.2 X-HELO: homiemail-a81.g.dreamhost.com Received: from caibbdcaabdd.dreamhost.com (HELO homiemail-a81.g.dreamhost.com) (208.113.200.133) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 Jan 2014 16:21:51 +0000 Received: from homiemail-a81.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a81.g.dreamhost.com (Postfix) with ESMTP id 5E7BBA806E; Fri, 31 Jan 2014 08:21:50 -0800 (PST) Received: from redwood.eagercon.com (c-24-7-16-38.hsd1.ca.comcast.net [24.7.16.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eager@eagerm.com) by homiemail-a81.g.dreamhost.com (Postfix) with ESMTPSA id 423CDA806C; Fri, 31 Jan 2014 08:21:50 -0800 (PST) Message-ID: <52EBCD9D.7030404@eagerm.com> Date: Fri, 31 Jan 2014 16:21:00 -0000 From: Michael Eager User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: gdb-patches ml CC: Keith Seitz Subject: Re: [PATCH] Regression setting breakpoint References: <52A8CD31.5090809@eagerm.com> In-Reply-To: <52A8CD31.5090809@eagerm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg01089.txt.bz2 Ping. Any comments? On 12/11/13 12:38, Michael Eager wrote: > There is a regression when setting a breakpoint which was introduced > in gdb-7.3 by a fix in this patch: > https://sourceware.org/ml/gdb-patches/2010-03/msg00220.html > > The regression shows up in C when the linkage name is different > from the internal symbol name. For example, > > void goo (int b) asm("_goo"); > void goo (int b) {} > > will create a function with the linkage name of "_goo" and the DWARF > will describe the source name of "goo". There is both a DW_AT_name and > DW_AT_linkage_name in the DIE for this function. Some compilers > (e.g., ICC) have options allowing linkage names to have characters > prepended to the source name so that the linkage name is different > from the source name and can not be computed from it. > > Prior to this patch, a breakpoint at "_goo" would find the linkage > symbol, and one at "goo" would find the source symbol. After the > patch, the source name is replace with the linkage name. > > The attached patch fixes this by making die_needs_namespace() > return 0 for any C language program. There's also a test case. > > I'm not sure that this is the right fix for the problem, although > I'm pretty sure that it should not break anything. There is code > in dwarf2_compute_name() which only calls die_needs_namespace() > for C++, Java, or Fortran programs, which could be moved into > die_needs_namespace(). Possibly the fix should be in dwarf2_physname() > where the call to die_needs_namespace() is done before the check for > DW_AT_linkage_name is done. > > Comment: Much of the code in dwarf2_compute_name(), dwarf2_physname(), > and related functions seems complex, convoluted, and confusing (the > big Three C's). The source name for a symbol is not the same as > the fully qualified name and it's not the same as the linkage name. > That a language supports FQNs with namespaces does not seem to me > to say that this should have anything to do with what the linkage (aka > physical) name for the symbol is. > -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077