From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31348 invoked by alias); 14 Oct 2013 16:29:19 -0000 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 Received: (qmail 31339 invoked by uid 89); 14 Oct 2013 16:29:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx-sanjose.cadence.com Received: from mx-sanjose.Cadence.COM (HELO mx-sanjose.cadence.com) (158.140.2.60) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 14 Oct 2013 16:29:18 +0000 Received: from exowa06sj.global.cadence.com (mailsj1-old.Cadence.COM [158.140.128.150]) by mx-sanjose.cadence.com (8.14.4/8.14.4) with ESMTP id r9EGQ3bm000482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Oct 2013 09:26:03 -0700 (PDT) Received: from MAILSJ3.global.cadence.com ([158.140.128.126]) by exowa06sj.global.cadence.com ([158.140.32.174]) with mapi; Mon, 14 Oct 2013 09:29:07 -0700 From: Arnab Bhaduri To: "gdb@sourceware.org" CC: Tom Tromey Date: Mon, 14 Oct 2013 16:29:00 -0000 Subject: RE: gdb not detecting function sections correctly for functions in overlays Message-ID: References: <8761t580mi.fsf@fleche.redhat.com> In-Reply-To: <8761t580mi.fsf@fleche.redhat.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Received: by mx-sanjose.cadence.com as r9EGQ3bm000482 at Mon Oct 14 09:26:03 2013 X-SW-Source: 2013-10/txt/msg00046.txt.bz2 Thanks for your reply. Yes, I came to the same conclusion after digging aro= und in the DWARF information. I had not been familiar with DWARF, or else I= might have reached that conclusion much sooner. I have made a couple of local changes that make things work better for me. = Perhaps you could give me your opinion on these (described below). 1) add_location_to_breakpoint() (breakpoint.c) - this calls set_breakpoint_= location_function() which sets the function name incorrectly because it use= s the PC-to-section lookup. I modified this like so: if the "symtab_and_lin= e * sal" argument's section is an overlay section, and sal->symtab is not n= ull, then walk over all the symbols in the symtab and find the one with a l= ine number that is closest to (but not larger than) the line number specifi= ed in the sal. With this best match symbol, search all the overlay sections= for a name match. If there is a match, select that overlay section and upd= ate the bp_location. Of course this will not work if e.g. I define two func= tions with the same name in two different overlays. In that case I warn the= user and arbitrarily choose the first one found. 2) find_function_start_sal() (symtab.c) - this calls find_pc_sect_line() to= look up the section, and fails when the PC-to-section lookup fails for ove= rlays. It was not clear to me why it does not use the symtab in the symbol = itself, which is passed in as an argument. I made a change here to use the = symbol's symtab if it has one. Arnab > -----Original Message----- > From: Tom Tromey [mailto:tromey@redhat.com] > Subject: Re: gdb not detecting function sections correctly for functions > in overlays >=20 > objdump --syms will show the ELF symbols, but not the DWARF symbols. > But if you have debuginfo, gdb will generally prefer the DWARF. > This may explain the discrepancy there. >=20 > Maybe this is a regression from my patch series to change how symbol > sections are represented. That would be my guess, anyway, if earlier > versions of gdb worked. >=20 > Anyway, there is no high road to fixing this -- just debugging gdb. >=20 > I don't think there's a good way of associating a DWARF symbol with a > particular overlay. That seems to be the root of the problem to me. >=20 > Tom