From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25170 invoked by alias); 10 Jun 2015 14:43:41 -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 25160 invoked by uid 89); 10 Jun 2015 14:43:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 10 Jun 2015 14:43:39 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id C059E8E667; Wed, 10 Jun 2015 14:43:38 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5AEhaTT014357; Wed, 10 Jun 2015 10:43:37 -0400 Message-ID: <55784D18.2000003@redhat.com> Date: Wed, 10 Jun 2015 14:43:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yao Qi , 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> In-Reply-To: <5578285D.2030808@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-06/txt/msg00186.txt.bz2 On 06/10/2015 01:06 PM, Yao Qi wrote: > On 10/06/15 11:17, Pedro Alves wrote: >> Hmm, does it really need to, though? We expose mechanisms like >> add-symbol-file, xml library list with qXfer:libraries:read (the default >> solib provider), xml target descriptions, "info os", etc., exactly so >> that GDB doesn't have to learn about the myriad of random RTOS's out there. > > If these stuffs (add-symbol-file, xml library list, etc) works well for > the given RTOS, and GDB doesn't need to know about the RTOS, that is > fine. However, in this case, Nucleus needs some changes in GDB c code > while GDB doesn't support Nucleus. I can't see how this patch benefits > any targets GDB supported. This is the reason I think this patch is > not acceptable. 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? 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. 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. I'd suspect that things are broken too when targets list relocatable objects in the qXfer:libraries:read list (in which case the target will list "section" elements instead of "segment" elements for each "library" element), and that's definitely meant to work. ("If the target supports dynamic linking of a relocatable object file, its library XML element should instead include a list of allocated sections.") Thanks, Pedro Alves