From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12904 invoked by alias); 10 Mar 2004 16:34:29 -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 12885 invoked from network); 10 Mar 2004 16:34:28 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 10 Mar 2004 16:34:28 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i2AGYP07003118 for ; Wed, 10 Mar 2004 11:34:25 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i2AGYOM10168 for ; Wed, 10 Mar 2004 11:34:25 -0500 Received: from cygbert.vinschen.de (vpn50-12.rdu.redhat.com [172.16.50.12]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i2AGYNR13934 for ; Wed, 10 Mar 2004 08:34:23 -0800 Received: by cygbert.vinschen.de (Postfix, from userid 500) id 641A1580E2; Wed, 10 Mar 2004 17:34:16 +0100 (CET) Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Corinna Vinschen To: gdb-patches@sources.redhat.com Subject: Re: [RFA] minsyms.c: Fix switching to GNU v3 ABI Message-ID: <20040310163416.GP25204@cygbert.vinschen.de> Reply-To: gdb-patches@sources.redhat.com Mail-Followup-To: gdb-patches@sources.redhat.com References: <20040310105709.GJ25204@cygbert.vinschen.de> <20040310150822.GA31014@nevyn.them.org> <20040310155450.GN25204@cygbert.vinschen.de> <20040310160410.GA410@nevyn.them.org> <20040310161617.GO25204@cygbert.vinschen.de> <20040310162011.GA1067@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040310162011.GA1067@nevyn.them.org> User-Agent: Mutt/1.4.2i X-RedHat-Spam-Score: -4.9 X-SW-Source: 2004-03/txt/msg00235.txt.bz2 On Mar 10 11:20, Daniel Jacobowitz wrote: > On Wed, Mar 10, 2004 at 05:16:17PM +0100, Corinna Vinschen wrote: > > On Mar 10 11:04, Daniel Jacobowitz wrote: > > > > > to me like you are having a problem with leading underscores, if I > > > > > remember my sh-elf-foo correctly. > > > > > > > > Could you tell more about that? I see a big bunch of symbols beginning > > > > with "__Z". Is that what you mean? > > > > > > Yes, precisely. On sh-elf all symbols are prefixed with an underscore. > > > I've been curious for a while about where, precisely, the leading > > > underscore is supposed to get stripped before we demangle; apparently, > > > the answer is "not early enough". > > > > Ok, I think I see now what happens. > > > > There are symbols beginning with "_Z" and (the most) beginning with "__Z". > > > > The symbols beginning with "_Z" are correctly recognized as language_cplus. > > > > The symbols beginning with "__Z" are still language_auto after > > prim_record_minimal_symbol_and_info has been called, since the demangler > > in libiberty doesn't recognize them. > > Wait a sec, why is that happening? Either everything should have a > leading _ or nothing should! I'm not sure if I understand the question. All symbols have leading underscores, some (actually just one!) have one underscore, all others have two underscores. I have no idea why that happens, it's what gcc 3.4 generates, I guess. I checked the C++ demangler in libiberty again and it requires that the symbols begin with "_Z", not with "__Z". > > So, after this loop SYMBOL_LINKAGE_NAME begins with "Z" for the first > > set of symbols (which *are* recognized as cplus variables) and with > > "_Z" for the second set of symbols (which are still auto). But now > > SYMBOL_DEMANGLED_NAME is only called for the second set of symbols > > and SYMBOL_DEMANGLED_NAME returns NULL for those symbols. > > > > What can we do?!? > > Move the check earlier? It should not be necessary to change > SYMBOL_LINKAGE_NAME. I think you could do this in > prim_record_minimal_symbol_and_info at the call site of > SYMBOL_SET_NAMES. I'm more and more under the impression that the problem is raised due to a bug in the symbol generation in gcc. It doesn't seem worth to change GDB proactively... Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12904 invoked by alias); 10 Mar 2004 16:34:29 -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 12885 invoked from network); 10 Mar 2004 16:34:28 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 10 Mar 2004 16:34:28 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i2AGYP07003118 for ; Wed, 10 Mar 2004 11:34:25 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i2AGYOM10168 for ; Wed, 10 Mar 2004 11:34:25 -0500 Received: from cygbert.vinschen.de (vpn50-12.rdu.redhat.com [172.16.50.12]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i2AGYNR13934 for ; Wed, 10 Mar 2004 08:34:23 -0800 Received: by cygbert.vinschen.de (Postfix, from userid 500) id 641A1580E2; Wed, 10 Mar 2004 17:34:16 +0100 (CET) Date: Wed, 10 Mar 2004 16:34:00 -0000 From: Corinna Vinschen To: gdb-patches@sources.redhat.com Subject: Re: [RFA] minsyms.c: Fix switching to GNU v3 ABI Message-ID: <20040310163416.GP25204@cygbert.vinschen.de> Reply-To: gdb-patches@sources.redhat.com Mail-Followup-To: gdb-patches@sources.redhat.com References: <20040310105709.GJ25204@cygbert.vinschen.de> <20040310150822.GA31014@nevyn.them.org> <20040310155450.GN25204@cygbert.vinschen.de> <20040310160410.GA410@nevyn.them.org> <20040310161617.GO25204@cygbert.vinschen.de> <20040310162011.GA1067@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040310162011.GA1067@nevyn.them.org> User-Agent: Mutt/1.4.2i X-RedHat-Spam-Score: -4.9 X-SW-Source: 2004-03.o/txt/msg00235.txt Message-ID: <20040310163400.yh8rka3Gc6DL6RTwLyEx0lMnzY83xsL5bKDEUmsOifs@z> On Mar 10 11:20, Daniel Jacobowitz wrote: > On Wed, Mar 10, 2004 at 05:16:17PM +0100, Corinna Vinschen wrote: > > On Mar 10 11:04, Daniel Jacobowitz wrote: > > > > > to me like you are having a problem with leading underscores, if I > > > > > remember my sh-elf-foo correctly. > > > > > > > > Could you tell more about that? I see a big bunch of symbols beginning > > > > with "__Z". Is that what you mean? > > > > > > Yes, precisely. On sh-elf all symbols are prefixed with an underscore. > > > I've been curious for a while about where, precisely, the leading > > > underscore is supposed to get stripped before we demangle; apparently, > > > the answer is "not early enough". > > > > Ok, I think I see now what happens. > > > > There are symbols beginning with "_Z" and (the most) beginning with "__Z". > > > > The symbols beginning with "_Z" are correctly recognized as language_cplus. > > > > The symbols beginning with "__Z" are still language_auto after > > prim_record_minimal_symbol_and_info has been called, since the demangler > > in libiberty doesn't recognize them. > > Wait a sec, why is that happening? Either everything should have a > leading _ or nothing should! I'm not sure if I understand the question. All symbols have leading underscores, some (actually just one!) have one underscore, all others have two underscores. I have no idea why that happens, it's what gcc 3.4 generates, I guess. I checked the C++ demangler in libiberty again and it requires that the symbols begin with "_Z", not with "__Z". > > So, after this loop SYMBOL_LINKAGE_NAME begins with "Z" for the first > > set of symbols (which *are* recognized as cplus variables) and with > > "_Z" for the second set of symbols (which are still auto). But now > > SYMBOL_DEMANGLED_NAME is only called for the second set of symbols > > and SYMBOL_DEMANGLED_NAME returns NULL for those symbols. > > > > What can we do?!? > > Move the check earlier? It should not be necessary to change > SYMBOL_LINKAGE_NAME. I think you could do this in > prim_record_minimal_symbol_and_info at the call site of > SYMBOL_SET_NAMES. I'm more and more under the impression that the problem is raised due to a bug in the symbol generation in gcc. It doesn't seem worth to change GDB proactively... Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc.