From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4A3573858D32; Thu, 13 Jul 2023 14:26:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4A3573858D32 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1689258418; bh=jXyCcly2OEyVIt6ZCKcZqX6TTgF3TbKX06PlumAOibc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=oT+xfRPAbEIYJoVzB7dsHaQvRbyeLm7UnX/zUzqrTIPkmbJj80zlRmumocyk7kxtM lkczPL4KQEAJ1YDKEWkFpg9EiDEYXHOaGWil9lZF8TUuWbACmIvQZEbMZvSOfc8Lkq 4krrXTu6SrgybFRZFhHx9mJ2uHmE3OJuPJRyIjLY= From: "mark at klomp dot org" To: gdb-prs@sourceware.org Subject: [Bug gdb/30541] Add target valgrind Date: Thu, 13 Jul 2023 14:26:58 +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: In-Reply-To: References: 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: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30541 --- Comment #29 from Mark Wielaard --- (In reply to Tom Tromey from comment #28) > I may not really understand the environment issue. >=20 > Using Q* to set the environment and the working directory seems > clearly better to me, and in fact the only way it can work > properly. The problem case is something like: >=20 > (gdb) set env X y > (gdb) start > (gdb) add-inferior blah blah > (gdb) set env X z > (gdb) start >=20 > Here, we've made 2 inferiors and started them with different environments. > The native target can simply pass this stuff to the inferior via > ordinary setenv stuff. For remotes, though, the inheritance can > only be done once, other inferiors are not fork'd by gdb. Note that vgdb doesn't implement multi-process mode. But it can easily start different processes (one after the other) with different environments. But I might not understand add-inferior correctly. > If Q* aren't working on the gdb side, let's make a new bug and > make it block this one. If they aren't working on the valgrind side, > I suggest a valgrind bug instead. We have QSetWorkingDir working and started implementing QEnvironment*, but there is no way to ask gdb to sent them. The user has to explicit replicate= the whole environment with gdb commands before gdb sents them to the remote. But maybe there is some way to request gdb to sent them explicitly? > A bonus of implementing vFile and Q* in valgrind is that then > "target remote | ssh machine vgdb" will work, which seems nice. In target remote mode it is kind of hard to make it work transparently, bec= ause then gdb/vgdb expect an already setup valgrind running on that machine. But with target extended-remote | ssh machine vgdb --multi, yeah, that would be nice. --=20 You are receiving this mail because: You are on the CC list for the bug.=