From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id C79333858C31; Tue, 11 Jul 2023 21:39:39 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C79333858C31
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1689111579;
	bh=6c0EYWGZSVexHjYX3o518RCLntjAtLz6Cbn53Ua6Bwk=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Ru+tmcgc5vH3+a5igBVgmrd1ow1cd/IpSDn7K6ZJT4JKvw0he45xaFOCCH3ZC8a+i
	 5j8Vyp25VombcIQWfSADs1C5A99buLyn64xi7XmcKXYp7E3Rxlu0aMes/fITAV9FUK
	 nt1FRJ5n59WMubx0wTTxseT46x/YynQw9RdNkcSM=
From: "mark at klomp dot org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/30541] Add target valgrind
Date: Tue, 11 Jul 2023 21:39:39 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: gdb
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mark at klomp dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-30541-4717-kqHx7xmt3e@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-30541-4717@http.sourceware.org/bugzilla/>
References: <bug-30541-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gdb-prs.sourceware.org>

https://sourceware.org/bugzilla/show_bug.cgi?id=3D30541

--- Comment #22 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Pedro Alves from comment #21)
> Just for the record:
>=20
> > to be clear, that would let us do "target remote -local HOST", for exam=
ple.)
>=20
> I think this would be a better approach than a new "target local-server".=
=20
> We use to have more variants of "target remote" and got them down to two
> "target remote" + "target extended-remote", and that's one too many still.
>=20
> Also since remote options are per-connection nowadays, we could have a
> corresponding "set remote local-filesystem" option, like we have matching
> "set print foo", and "print -foo".  The set option would also let you do
> "with remote local-filesystem -- target remote | valgrind".

Note that there are a couple more "remote local" issues beside the filesyst=
em.

There is the environment variables, currently we rely on target extended-re=
mote
| vgdb --multi started the vgdb process with the same environment that the
current gdb process has (important for example for PATH or LD_LIBRARY_PATH
settings).
And there is the current working directory, which we also rely on getting
inherited by being launched by gdb.

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 li=
ke
gdb has them. It would be nice to have a way to request and/or explicitly s=
et
both the environment and cwd as gdb knows them for a "remote local" setup.

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