[PATCH 0/6] Add vDefaultInferiorFd feature

[Andrew Burgess]

Tom Tromey <tom@tromey.com> writes:

>>>>>> "Alexandra" == Alexandra Hájková <ahajkova@redhat.com> writes:
>
> FWIW I tend to think Pedro ought to review this, since he's got the most
> up-to-date experience with terminal handling, etc; or at least more so
> than I do.
>
> I do have a few comments on the implementation, but before that, I
> wanted to ask a bit about the overall approach.
>
> Alexandra> Currently, when GDBserver is run locally using stdio, the inferior
> Alexandra> is unable to read from STDIN so we can't give it any input.
>
> This idea in general seems fine to me (pending Pedro's input).
> It's also in line with, and probably needed by, the idea of moving gdb
> to a "gdbserver-only" model:
>
> https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity
>
> It's never been super clear to me if gdbserver-only is a real goal or
> just something we talk about idly.  I've been on the fence about it
> myself, though more recently I tend to like the idea, simply because it
> means less work -- I've written a number of patches now that needed work
> on both gdb and gdbserver, and this project would halve that kind of
> effort.

I wouldn't describe it as the only thing I'm working on, but this is,
lets say, my background goal, part of my 10 year plan :)

I suspect my motivation is the same as yours -- the code duplication
between GDB and gdbserver is annoying.  And even if we managed some
super code refactor, and managed to share 100% of the native handling
code between GDB and gdbserver, I suspect simply having the remote
interface in-between would introduce its only differences.  Better, I
think, to have just one way of doing things.

Honestly, I suspect I may never get there, there are just too many
distractions, but I'm hoping to work on closing the gap between native
and remote over the next couple of years.  Then, maybe, who knows...

Anyway, I just thought I'd register my very real interest in working
towards a remote-only setup.

Thanks,
Andrew




>
> Alexandra> Add a new DefaultInferiorFd feature and the corresponding packet.
>
> One question I had is - why a new packet?  A new packet seems somewhat
> weird, in that it's only valid pretty early during startup, it seems.
>
> Another approach might be to have a different way to specify the
> connection fd to the remote, like a command-line option naming the fd to
> use for RSP traffic.
>
> Tom