[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 #33 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Pedro Alves from comment #32)
> > 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).
> 
> Not sure if I fully understood that approach.

The basic idea is that gdb would dup the normal stdin/out/err and let the
gdbserver/vgdb inherit those file descriptors. Then gdb will sent a new
fdSwitch packet to notify that gdbserver/gdb should switch around its own
stdin/out/err with those file descriptors (and make any inferiors started use
those) and move the original stdin/out file descriptors so packets aren't sent
anymore over stdin/out.

> But, wouldn't it be simpler to teach GDB an alternative to "target
> extended-remote | CMD".
> 
> Like:
> 
>   target extended-remote -server-cmd "vgdb --multi :9999" :9999
> 
> "-server-cmd CMD" would spawn CMD, and GDB would wait/reap it like it does
> for "target extended-remote | CMD".
> 
> You could replace ":9999" with a unix domain socket, created by the "target
> valgrind" command, for example.
> 
> That would leave stdin/stdout/stderr to be used by gdbserver as normal.

Andrew also suggested something like that (replace | with some other magic
char) to get that effect. Maybe

> Terminal handling, for getting input into the inferior, yeah, that is a
> little complex. You have to put vgdb in the foreground whenever gdb wants to
> give the terminal to the inferior.

Maybe this part of the conversation should move to bug #28916
I think I am a little naive and was just hoping having a shared stdin between
gdb/gdbserver/inferior would be enough to get the inferior normal reading from
stdin. I didn't realize the terminal needed to know who is reading. But I
already noticed it totally messes up ^C handling... hohum.

Having stdout work would already be an improvement. gdbserver has a trick for
that which vgdb should probably just add too (redirect stdout to stderr for the
inferior).
https://bugs.kde.org/show_bug.cgi?id=471311

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