From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0656A3858002; Thu, 13 Jul 2023 13:59:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0656A3858002 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1689256775; bh=Gl+S9uR6MYe02w8T9xXGYbpyF/ACSl6lzG76HNNjeME=; h=From:To:Subject:Date:In-Reply-To:References:From; b=g34C3vogPUyW1CPu+EAh8jf4xyPxEyklOLFONu+nahd0ZxSQzE8THkMyHj0VAkBb4 ASeW32FK5hpTEDXZKxDcN7ZzWIXgUAQcGw3/scYj5XsBkT/LegmUNWQ8pBvii8vZPo sPvivXn4apGcaGT8pNgwOiQVspSjlmkLdYGZ9pq0= From: "mark at klomp dot org" To: gdb-prs@sourceware.org Subject: [Bug gdb/30541] Add target valgrind Date: Thu, 13 Jul 2023 13:59:34 +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 #27 from Mark Wielaard --- (In reply to Pedro Alves from comment #23) > > 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= like gdb has them.=20 > > It would be nice to have a way to request and/or explicitly set both th= e environment and cwd as gdb knows them for a "remote local" setup. >=20 > Can you expand a bit more on how you'd see that working, on what is the u= se > case for connecting via socket like? Is that about users spawning vgdb > themselves, or there being some central vgdb service or the like? We prefer vgdb being launched from within gdb (target extended-remote | vgdb --multi) and get the environment/cwd inherited that way. But currently that means vgdb will communicate through stdin/out with gdb, = so stdin/out aren't available for the inferior. This is being worked on by Sas= ha for https://sourceware.org/bugzilla/show_bug.cgi?id=3D28916 at https://git.sr.ht/~sasshka/binutils-gdb/log/split_fd but we aren't there yet (switching the file descriptors used for communication seems to work, but t= he whole terminal handling is a little complex). So for programs that currently need to work with "normal" stdin/out you'll = have to run in a separate terminal with vgdb --multi --port 5555 and then in gdb= use terget extended-remote :5555 > It just seems like setting up environment and cwd could be done by a wrap= per > script or whatever invokes vgdb. But who or what would create such a wrapper script? Why not simply sent the gdb environment and cwd through QSetWorkingDir and QEnvironment* when we can detect the remote would like the environment to be like the gdb environment? --=20 You are receiving this mail because: You are on the CC list for the bug.=