From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19728 invoked by alias); 26 Jan 2007 19:41:00 -0000 Received: (qmail 19719 invoked by uid 22791); 26 Jan 2007 19:40:59 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.palmsource.com (HELO mx2.palmsource.com) (12.7.175.14) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 26 Jan 2007 19:40:54 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id C83E010A7B1; Fri, 26 Jan 2007 11:40:51 -0800 (PST) Received: from mx2.palmsource.com ([127.0.0.1]) by localhost (mx2.palmsource.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00646-01-38; Fri, 26 Jan 2007 11:40:48 -0800 (PST) Received: from ussunex01.palmsource.com (unknown [192.168.101.9]) by mx2.palmsource.com (Postfix) with ESMTP id 8E905107140; Fri, 26 Jan 2007 11:19:23 -0800 (PST) Received: from 192.168.92.105 ([192.168.92.105]) by ussunex01.palmsource.com ([192.168.101.9]) via Exchange Front-End Server owa.palmsource.com ([10.0.20.17]) with Microsoft Exchange Server HTTP-DAV ; Fri, 26 Jan 2007 19:19:23 +0000 Received: from svkmacdonelllnx by owa.palmsource.com; 26 Jan 2007 11:26:30 -0800 Subject: Re: Breaking on C labels? From: Michael Snyder To: Jim Blandy Cc: Joel Brobecker , gdb@sourceware.org In-Reply-To: References: <20070125194905.GB4262@adacore.com> <1169767203.22601.128.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 26 Jan 2007 19:41:00 -0000 Message-Id: <1169839590.14604.31.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00333.txt.bz2 On Fri, 2007-01-26 at 10:55 -0800, Jim Blandy wrote: > Michael Snyder writes: > > There's a risk that some symbol-lookup function would then select that > > label instead of the function entry label when you tried to look up the > > nearest label preceeding a given address. > > This should be easy to avoid, shouldn't it? We would only recognize > LOC_LABEL entries for breakpoints, and ignore them for lookups by > address. I'm not sure, it's too long since I looked at it. Are you sure LOC_LABEL is the correct attribute? Seems to me, that might be what is used by the compiler for all those ".L123" labels that it uses for loop control etc. You don't want to get mixed up with those, because there's a bazillion of them, and we want them to get stripped out by the linker.