Re: [PATCH v5] Implement the ability to set/unset environment variables to GDBserver when starting the inferior

[Thomas Preudhomme <thomas.preudhomme@foss.arm.com>]

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.
>