[Bug gdb/30541] Add target valgrind

["mark at klomp dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30541

--- Comment #29 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Tom Tromey from comment #28)
> I may not really understand the environment issue.
> 
> Using Q* to set the environment and the working directory seems
> clearly better to me, and in fact the only way it can work
> properly.  The problem case is something like:
> 
> (gdb) set env X y
> (gdb) start
> (gdb) add-inferior blah blah
> (gdb) set env X z
> (gdb) start
> 
> Here, we've made 2 inferiors and started them with different environments.
> The native target can simply pass this stuff to the inferior via
> ordinary setenv stuff.  For remotes, though, the inheritance can
> only be done once, other inferiors are not fork'd by gdb.

Note that vgdb doesn't implement multi-process mode. But it can easily start
different processes (one after the other) with different environments. But I
might not understand add-inferior correctly.

> If Q* aren't working on the gdb side, let's make a new bug and
> make it block this one.  If they aren't working on the valgrind side,
> I suggest a valgrind bug instead.

We have QSetWorkingDir working and started implementing QEnvironment*, but
there is no way to ask gdb to sent them. The user has to explicit replicate the
whole environment with gdb commands before gdb sents them to the remote. But
maybe there is some way to request gdb to sent them explicitly?

> A bonus of implementing vFile and Q* in valgrind is that then
> "target remote | ssh machine vgdb" will work, which seems nice.

In target remote mode it is kind of hard to make it work transparently, because
then gdb/vgdb expect an already setup valgrind running on that machine. But
with target extended-remote | ssh machine vgdb --multi, yeah, that would be
nice.

-- 
You are receiving this mail because:
You are on the CC list for the bug.