From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120025 invoked by alias); 10 Jun 2015 11:46:02 -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 120016 invoked by uid 89); 10 Jun 2015 11:46:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 10 Jun 2015 11:46:01 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1Z2eSD-0000PE-PP from Taimoor_Mirza@mentor.com ; Wed, 10 Jun 2015 04:45:58 -0700 Received: from [137.202.157.84] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 10 Jun 2015 12:45:56 +0100 Message-ID: <55782370.50003@codesourcery.com> Date: Wed, 10 Jun 2015 11:46:00 -0000 From: Taimoor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Luis Machado , Yao Qi CC: "gdb-patches@sourceware.org" Subject: Re: Improving GDB's mechanism to check if function is GC'ed References: <556DB1BB.50601@codesourcery.com> <86eglkeyfw.fsf@gmail.com> <55781D03.5070003@codesourcery.com> In-Reply-To: <55781D03.5070003@codesourcery.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00172.txt.bz2 On 06/10/2015 04:18 PM, Luis Machado wrote: > On 06/10/2015 05:53 AM, Yao Qi wrote: >> Taimoor writes: >> >> Hi Taimoor, >> I happen to have to some time today to read your patch, here are my >> comments below, >> >>> >>> Current Problem >>> =============== >>> >>> We are currently using GDB to debug Nucleus based bare-metal system >>> that also allows to dynamically load and unload Nucleus process >>> modules during system execution. >>> We currently load symbols of a modules using add-symbol-file whenever >>> a module is loaded at runtime. It is very common to have functions at >>> address 0x0 in debug information and then lowpc in symbol table to be >>> non-zero as it depends on section addresses given in add-symbol-file >>> command. >> >> GDB just uses some heuristics to determine whether the function is GC'ed >> by linker, so they may not be perfect. However, GDB doesn't support >> Nucleus, so it isn't a valid case to me. Do we have other cases that we >> add-symbol-file in which function address is at 0x0 on platforms GDB >> supports? >> >> If the problem only exists on Nucleus, I am afraid I don't agree with >> accepting this change, because GDB doesn't support Nucleus. Sorry. > > add-symbol-file can cause things to get weird with addresses given the > user can specify the base address as it pleases. I don't think this is > Nucleus-specific at all, but more generally bare-metal-specific. > > I take it DWARF says 0x0 and GDB relocates the symbol file/addresses > based on the provided base address? Taimoor? Yes. Its not something specific to Nucleus. Only issue is that function address in DWARF is 0x0 as this object file is loaded at runtime and its symbols are added using "add-symbol-file" command on the basis of address space where it is loaded. IMO, for any dynamic relocatable object, GDB provides a mechanism to load its symbols using add-symbol-file. But if that object file has function at 0x0, current mechanism consider it GC'ed. Thanks, Taimoor