From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42251 invoked by alias); 6 Sep 2017 08:36:21 -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 42232 invoked by uid 89); 6 Sep 2017 08:36:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=talk X-HELO: foss.arm.com Received: from usa-sjc-mx-foss1.foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Sep 2017 08:36:19 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BC1BC13D5; Wed, 6 Sep 2017 01:36:17 -0700 (PDT) Received: from [10.2.206.52] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0436D3F483; Wed, 6 Sep 2017 01:36:16 -0700 (PDT) Subject: Re: [PATCH v5] Implement the ability to set/unset environment variables to GDBserver when starting the inferior To: Simon Marchi , Sergio Durigan Junior Cc: GDB Patches References: <20170629194106.23070-1-sergiodj@redhat.com> <20170831204932.25219-1-sergiodj@redhat.com> <87o9qv5sza.fsf@redhat.com> <2aea3170-004a-bfe1-3e57-f7e3238167fb@foss.arm.com> <76dbbf5e-2ff1-1651-c988-b8b93da4e8bd@ericsson.com> <9a49351b-97ec-663b-3464-f7798117df05@foss.arm.com> <526a7ca9-6562-91d7-1c7a-d8d692967395@ericsson.com> From: Thomas Preudhomme Message-ID: <59e18d0e-3114-2019-04e3-0dbd661ca987@foss.arm.com> Date: Wed, 06 Sep 2017 08:36:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <526a7ca9-6562-91d7-1c7a-d8d692967395@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00141.txt.bz2 Hi Simon, Thanks for clarifying things up. Sorry for the noise then. Best regards, Thomas On 05/09/17 19:41, Simon Marchi wrote: > On 2017-09-05 07:09 PM, Thomas Preudhomme wrote: >> Hi Simon, >> >> Sorry if I wasn't clear. I actually meant that this test *should* be relevant >> for cross-debugger using native gdbserver but it is currently skipped in that >> case (because the test only checks if that gdb uses a stub). > > The native in native-gdbserver (as in --target_board=native-gdbserver) means > that we are testing against a gdbserver compiled for the same architecture as > the build machine. Moreover, that board happens to spawn gdbserver locally, on > the same machine that runs the testsuite. It's easy to build & test this > configuration, since you can do everything on the same machine. If you build a > cross-debugger, it means that the architecture where gdb runs is different from > the architecture gdbserver runs and debug. It kind of doesn't make sense to > use the native-gdbserver board when testing a cross debugger, since it would > imply that gdb and gdbserver run the same architecture, but then it's not a > cross-debugger... > > You can (and maybe you already do) write your own board file in order to test a > cross-debugger. [1] > > The reason why native-gdbserver is not relevant in that case is that it uses > the "remote" protocol, as opposed to the "extended-remote" protocol as used by > the native-extended-gdbserver board. A difference between the two is that only > in extended-remote can you spawn/run new processes. And setting the > environment variables in GDB with "set environment" only affects processes > created by gdb (and now gdbserver). This is why it doesn't make sense to run > the test with native-gdbserver (or anything that uses the non-extended "remote" > protocol). > >> Did I misunderstand the meaning of gdb stub? > > The way I understand it is that a "gdb stub" is a debugging interface that > talks the non-extended remote protocol and is embedded in whatever you try to > debug [2]. Therefore, there's no notion of starting a new process. When you > connect to it, the thing already exists. And if it exits, the remote > connection dies with it, since you don't have anybody to talk to anymore. So > with a GDB stub, you would always talk the remote protocol, not > extended-remote. In the testsuite, "use_gdb_stub" is pretty much equivalent to > the "remote" protocol. When using the native-extended-remote board file, you > are not using the extended-remote protocol, and can create new processes, and > therefore it's !use_gdb_stub. > > Hopefully that help clear things up. > > [1] https://sourceware.org/gdb/wiki/TestingGDB#Testing_gdbserver_in_a_remote_cross-target_configuration > [2] Of course, gdbserver is not embedded in what you try to debug, but it's > the same result, it has the same lifetime. >