From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 410 invoked by alias); 12 Jul 2008 07:41:09 -0000 Received: (qmail 400 invoked by uid 22791); 12 Jul 2008 07:41:08 -0000 X-Spam-Check-By: sourceware.org Received: from host0.dyn.jankratochvil.net (HELO host0.dyn.jankratochvil.net) (89.250.240.59) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 12 Jul 2008 07:40:33 +0000 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.2/8.14.2) with ESMTP id m6C7dd4P022468; Sat, 12 Jul 2008 09:39:39 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.2/8.14.2/Submit) id m6C7dYC1022467; Sat, 12 Jul 2008 09:39:34 +0200 Date: Sat, 12 Jul 2008 07:41:00 -0000 From: Jan Kratochvil To: gdb-patches@sourceware.org Cc: Daniel Jacobowitz Subject: Re: [FYI] Inlining support, rough patch [break-by-function-name] Message-ID: <20080712073934.GA22282@host0.dyn.jankratochvil.net> References: <20080613152754.GA4220@caradoc.them.org> <20080623115422.GA17511@host0.dyn.jankratochvil.net> <20080702191438.GA3735@caradoc.them.org> <20080703112148.GA30899@host0.dyn.jankratochvil.net> <20080703160102.GA24817@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080703160102.GA24817@caradoc.them.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-IsSubscribed: yes 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 X-SW-Source: 2008-07/txt/msg00231.txt.bz2 On Thu, 03 Jul 2008 18:01:02 +0200, Daniel Jacobowitz wrote: > On Thu, Jul 03, 2008 at 01:21:48PM +0200, Jan Kratochvil wrote: > > On Wed, 02 Jul 2008 21:14:38 +0200, Daniel Jacobowitz wrote: > > ... > > > Let's wait on that until the rest of the patch is ready, though. > > > I'm making good progress. > > > > That would be great, while discussing the uncommitted patches here is one on > > top of it to make `break inlined_function' work with the multi-PC breakpoints. ... > I can't see how this works, unless you're getting lucky. The only risk is code in multiple sections - but for non-embedded targets all the final linked regular code possibly containing inlined concrete instances is in .text. > For instance > here: > > @@ -5692,7 +5692,7 @@ resolve_sal_pc (struct symtab_and_line * > > bv = blockvector_for_pc_sect (sal->pc, 0, &b, sal->symtab); > > if (bv != NULL) > > { > > - sym = block_linkage_function (b); > > + sym = block_function (b); > > if (sym != NULL) > > { > > fixup_symbol_section (sym, sal->symtab->objfile); > > fixup_symbol_section is a symbol lookup. There has to be a real > function in the ELF symbol table with the same name, and here that > may be in a different section entirely. This problem should be fixed since: [commit] Handle minimal symbols pointing to function descriptors http://sourceware.org/ml/gdb-patches/2008-05/msg00120.html fixup_section(): - if (msym) + /* First, check whether a minimal symbol with the same name exists + and points to the same address. The address check is required + e.g. on PowerPC64, where the minimal symbol for a function will + point to the function descriptor, while the debug symbol will + point to the actual function code. */ + if (msym + && SYMBOL_VALUE_ADDRESS (msym) == ginfo->value.address) Which is followed by `ginfo->value.address' lookup in the section table. Thanks for the problem notice, Jan