public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: "Tom Tromey" <tom@tromey.com>, "Alexandra Hájková" <ahajkova@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 0/6] Add vDefaultInferiorFd feature
Date: Mon, 04 Dec 2023 11:08:14 +0000	[thread overview]
Message-ID: <87r0k2gr8h.fsf@redhat.com> (raw)
In-Reply-To: <874jh1brln.fsf@tromey.com>

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


  reply	other threads:[~2023-12-04 11:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-17 11:18 Alexandra Hájková
2023-11-17 11:18 ` [PATCH 1/6] gdb.server/non-existing-program.exp: Use gdbserver_start Alexandra Hájková
2023-11-17 11:18 ` [PATCH 2/6] gdb/ser-pipe.c: Duplicate the file descriptors Alexandra Hájková
2023-12-12 19:42   ` Tom Tromey
2023-11-17 11:18 ` [PATCH 3/6] Add new vDefaultInferiorFd packet Alexandra Hájková
2023-11-17 12:09   ` Eli Zaretskii
2023-12-12 20:03   ` Tom Tromey
2023-11-17 11:18 ` [PATCH 4/6] gdbserver/linux-low.cc: Connect the inferior to the terminal Alexandra Hájková
2023-12-12 20:10   ` Tom Tromey
2023-11-17 11:18 ` [PATCH 5/6] remote.c: Add terminal handling functions Alexandra Hájková
2023-12-12 20:11   ` Tom Tromey
2023-11-17 11:18 ` [PATCH 6/6] Add defaultinf.exp test to the testsuite Alexandra Hájková
2023-11-27 10:01 ` [PATCH 0/6] Add vDefaultInferiorFd feature Alexandra Petlanova Hajkova
2023-12-01 20:22 ` Tom Tromey
2023-12-04 11:08   ` Andrew Burgess [this message]
2023-12-04 12:11   ` Alexandra Petlanova Hajkova
2023-12-05 16:00     ` Tom Tromey
2023-12-08 13:06       ` Andrew Burgess
2023-12-12 20:14   ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r0k2gr8h.fsf@redhat.com \
    --to=aburgess@redhat.com \
    --cc=ahajkova@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).