From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82469 invoked by alias); 10 Jun 2015 12:25:15 -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 82418 invoked by uid 89); 10 Jun 2015 12:25:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f46.google.com Received: from mail-pa0-f46.google.com (HELO mail-pa0-f46.google.com) (209.85.220.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 10 Jun 2015 12:25:10 +0000 Received: by payr10 with SMTP id r10so34134070pay.1 for ; Wed, 10 Jun 2015 05:25:09 -0700 (PDT) X-Received: by 10.68.57.209 with SMTP id k17mr5499437pbq.118.1433939109112; Wed, 10 Jun 2015 05:25:09 -0700 (PDT) Received: from [127.0.0.1] (gcc1-power7.osuosl.org. [140.211.15.137]) by mx.google.com with ESMTPSA id e9sm8590955pat.33.2015.06.10.05.25.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2015 05:25:06 -0700 (PDT) Message-ID: <55782C9B.50005@gmail.com> Date: Wed, 10 Jun 2015 12:25:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Taimoor , Luis Machado 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> <55782370.50003@codesourcery.com> In-Reply-To: <55782370.50003@codesourcery.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00177.txt.bz2 On 10/06/15 12:45, Taimoor wrote: > > 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. Could you help me to understand how to reproduce this problem on any GDB supported targets? Your fix may not be Nucleus specific, but I think the problem does only exist on Nucleus, please correct me if I am wrong. -- Yao (齐尧)