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

[Simon Marchi <simon dot marchi at ericsson dot com>]

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.