From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22426 invoked by alias); 10 Jun 2015 12:07:04 -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 22416 invoked by uid 89); 10 Jun 2015 12:07:03 -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-f43.google.com Received: from mail-pa0-f43.google.com (HELO mail-pa0-f43.google.com) (209.85.220.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 10 Jun 2015 12:07:02 +0000 Received: by pabqy3 with SMTP id qy3so33674690pab.3 for ; Wed, 10 Jun 2015 05:07:01 -0700 (PDT) X-Received: by 10.66.231.42 with SMTP id td10mr5229761pac.98.1433938021016; Wed, 10 Jun 2015 05:07:01 -0700 (PDT) Received: from [127.0.0.1] (gcc1-power7.osuosl.org. [140.211.15.137]) by mx.google.com with ESMTPSA id jx5sm8477251pbc.85.2015.06.10.05.06.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2015 05:07:00 -0700 (PDT) Message-ID: <5578285D.2030808@gmail.com> Date: Wed, 10 Jun 2015 12:07: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> In-Reply-To: <55780EB4.1070003@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00176.txt.bz2 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. -- Yao (齐尧)