From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 7CA543858C5E for ; Mon, 4 Dec 2023 11:08:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7CA543858C5E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7CA543858C5E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701688109; cv=none; b=kbrBPU2K+CLgAQSDmS7wy7Kd1n9xF+uvEYfFjfWAow4v2uMGU+y+Ainds/ALVhomL/QILYmbmrQ1GBKKb7UgK7TQPmGvU+cFVC4khBatklV5a57CwSCfQcyuVJ9haytliUYRJ6sr/abXggje45vBZ9/AxXeGpp+19NK8MAeJyQ4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701688109; c=relaxed/simple; bh=6tYQgfAAT2rVf2CUivFDRDPJIvGGsLzWU6WC2S2J8uM=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=Vc3ijQQd1yS1pxh5QCKoBmMcuB1ZjTqeR/lqhye5eZ/KSub0ulOQi4hfvm0lFAYYSclCsf2aKn2xX9/+msnUIW8z3O3N7uET98gHWHi7ZfEf4x7Pyl2svIOvrv9QYynluUH5mT37yCbiNjhGNI0H5+gKUrPY2eHr3vZxGq3+tFQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701688099; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9b2dN1RPNvxbTkR4A689reB2a+wT6R1kQmU9XrHJAxA=; b=Ux4HxieWvCyjv6EJffJoGqmGKjjxr/vKZDLYPQgp+ttnsGH0AeEasOUnpIjJpAqm1rox0T KXbWIbF8gdnbb7iRnduOc3J/B/vvNx5UdqU9iYjAjEOC/x9FsFiOgas5MDbY/fvAGyejT2 82CzE58igpHNZSQCsRP6s2XRs/fKc74= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-693-I5BZttkkN6CYHzGDiBFu7g-1; Mon, 04 Dec 2023 06:08:17 -0500 X-MC-Unique: I5BZttkkN6CYHzGDiBFu7g-1 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-332ee20a40fso3409549f8f.3 for ; Mon, 04 Dec 2023 03:08:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701688097; x=1702292897; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9b2dN1RPNvxbTkR4A689reB2a+wT6R1kQmU9XrHJAxA=; b=PmUUtkphczhX7qlXg5Ji2l338LOMjpoUY1vdfeUCrgbskKUcRjiZvWjAkdo7Ge4Xbx YgWVvNNtLuIrxKEZAVhQo/iwsCh/p9/8YdLT6sE6jHVSgLluIYxKmIqWJxoBvwNd8YhX NOTJ7KALaywD4X3BA0X3c75RMGpghPCPaSNw65axIN5TplpKlObM3trtqcCYrdG2UZlz xY3PCjic8AOvJe6XQw3yC4MA2gStpatI7UXF+YxtoNX3lbS14xbbHM5X+Ekzcl1ah5/U 8FYzBdi2MNIAcv8nxNDmH+X6uuoDPAKmZYwhR6fOy8nevUkaM65jXFn4Tf+3nMLhFnbh R/wg== X-Gm-Message-State: AOJu0YwDjxeuurNQqT8Ats46px6IkfyFpbv7inr85v5p2KoZn6pMVSYJ SY2Fg7iL2JL97jthHml6ixrU3EU1wLHe/CptMyBiNnA/LRiicff7W3Ua7LJWiN5gESazfSywUQt PuC/DneQwKoJExzmCK9gmyA== X-Received: by 2002:a05:600c:ad2:b0:40b:5e59:e9f6 with SMTP id c18-20020a05600c0ad200b0040b5e59e9f6mr2412993wmr.149.1701688096785; Mon, 04 Dec 2023 03:08:16 -0800 (PST) X-Google-Smtp-Source: AGHT+IEZ/725RNdpPpnP8lMF6XLSnW5kqD/z6a4lVVbkKJEhnVmvn668rbuG+5YR3nc9oYd7jMqz/g== X-Received: by 2002:a05:600c:ad2:b0:40b:5e59:e9f6 with SMTP id c18-20020a05600c0ad200b0040b5e59e9f6mr2412988wmr.149.1701688096473; Mon, 04 Dec 2023 03:08:16 -0800 (PST) Received: from localhost (105.226.159.143.dyn.plus.net. [143.159.226.105]) by smtp.gmail.com with ESMTPSA id p6-20020a05600c468600b0040c0902dc22sm5009385wmo.31.2023.12.04.03.08.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Dec 2023 03:08:15 -0800 (PST) From: Andrew Burgess To: Tom Tromey , Alexandra =?utf-8?B?SMOhamtvdsOh?= Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 0/6] Add vDefaultInferiorFd feature In-Reply-To: <874jh1brln.fsf@tromey.com> References: <20231117111840.2040709-1-ahajkova@redhat.com> <874jh1brln.fsf@tromey.com> Date: Mon, 04 Dec 2023 11:08:14 +0000 Message-ID: <87r0k2gr8h.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Tom Tromey writes: >>>>>> "Alexandra" =3D=3D Alexandra H=C3=A1jkov=C3=A1 = 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 infe= rior > 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 pack= et. > > 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