[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 #27 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Pedro Alves from comment #23)
> > For both these issues things stop working when we launch things through a socket, even though there are gdb remote protocol packets to set them up like gdb has them. 
> > It would be nice to have a way to request and/or explicitly set both the environment and cwd as gdb knows them for a "remote local" setup.
> 
> Can you expand a bit more on how you'd see that working, on what is the use
> case for connecting via socket like?  Is that about users spawning vgdb
> themselves, or there being some central vgdb service or the like?

We prefer vgdb being launched from within gdb (target extended-remote | vgdb
--multi) and get the environment/cwd inherited that way.

But currently that means vgdb will communicate through stdin/out with gdb, so
stdin/out aren't available for the inferior. This is being worked on by Sasha
for https://sourceware.org/bugzilla/show_bug.cgi?id=28916 at
https://git.sr.ht/~sasshka/binutils-gdb/log/split_fd but we aren't there yet
(switching the file descriptors used for communication seems to work, but the
whole terminal handling is a little complex).

So for programs that currently need to work with "normal" stdin/out you'll have
to run in a separate terminal with vgdb --multi --port 5555 and then in gdb use
terget extended-remote :5555

> It just seems like setting up environment and cwd could be done by a wrapper
> script or whatever invokes vgdb.

But who or what would create such a wrapper script?

Why not simply sent the gdb environment and cwd through QSetWorkingDir and
QEnvironment* when we can detect the remote would like the environment to be
like the gdb environment?

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