From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33214 invoked by alias); 11 Jun 2015 08:30:46 -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 33203 invoked by uid 89); 11 Jun 2015 08:30:45 -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-pd0-f181.google.com Received: from mail-pd0-f181.google.com (HELO mail-pd0-f181.google.com) (209.85.192.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 11 Jun 2015 08:30:44 +0000 Received: by pdbki1 with SMTP id ki1so175287pdb.1 for ; Thu, 11 Jun 2015 01:30:42 -0700 (PDT) X-Received: by 10.66.194.201 with SMTP id hy9mr13218150pac.140.1434011442821; Thu, 11 Jun 2015 01:30:42 -0700 (PDT) Received: from [127.0.0.1] (gcc1-power7.osuosl.org. [140.211.15.137]) by mx.google.com with ESMTPSA id nz2sm10761976pbb.40.2015.06.11.01.30.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2015 01:30:42 -0700 (PDT) Message-ID: <5579472A.6020200@gmail.com> Date: Thu, 11 Jun 2015 08:30: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: Pedro Alves , Taimoor 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> <55780EB4.1070003@redhat.com> <5578285D.2030808@gmail.com> <55784D18.2000003@redhat.com> In-Reply-To: <55784D18.2000003@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00201.txt.bz2 On 10/06/15 15:43, Pedro Alves wrote: > This strikes me as an odd position, given the whole point of those commands > and features is letting GDB support the target without builtin knowledge of > them, so it's natural that GDB didn't have built-in support for the target > thus far. But now we broke one of the mechanisms for some use case. > Put another way, if we added support for --target=$cpu-nucleus, just as a > configure alias for --target=$cpu-elf, so that we could say we supported > Nucleus, how would we go about fixing this? Even Nucleus is supported in GDB, I don't know how to fix this problem either. If this problem only exist on Nucleus, do we need to fix this problem? > > I think we need to look and understand_why_ Nucleous' binaries trigger > the problem. If they're standard elf, it just looks to me that Nucleous > is a red herring. I agree that we need look deep and understand why Nucleus binaries trigger this problem, to see whether it is Nucleus specific or not. > > IIUC, this triggers on use of add-symbol-file with relocatable > objects, when there's real code at address 0. I think that's the angle > we should look at things. > Yes, that is the problem. GDB thinks the function is GC'ed by linker but in fact it isn't. -- Yao (齐尧)