From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103145 invoked by alias); 5 Mar 2015 13:39:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 103135 invoked by uid 89); 5 Mar 2015 13:39:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 05 Mar 2015 13:39:23 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t25DdM69031842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 5 Mar 2015 08:39:22 -0500 Received: from blade.nx (ovpn-116-103.ams2.redhat.com [10.36.116.103]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t25DdLHX032693; Thu, 5 Mar 2015 08:39:22 -0500 Received: by blade.nx (Postfix, from userid 1000) id 3D20926506C; Thu, 5 Mar 2015 13:39:21 +0000 (GMT) Date: Thu, 05 Mar 2015 13:39:00 -0000 From: Gary Benson To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 0/2] Use gdb_sysroot for main executable on attach Message-ID: <20150305133921.GB23865@blade.nx> References: <1425555461-22093-1-git-send-email-gbenson@redhat.com> <201503051248.t25CmnZH014990@glazunov.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201503051248.t25CmnZH014990@glazunov.sibelius.xs4all.nl> X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00152.txt.bz2 Mark Kettenis wrote: > > From: Gary Benson > > > > This series modifies GDB to prefix the main executable's path with > > gdb_sysroot under certain circumstances, namely: > > > > * The path supplied by target_pid_to_exec_file is absolute, and > > * gdb_sysroot is set and not remote. > > > > This logic is skipped for remote gdb_sysroots because the subsequent > > code does not support opening the main executable over the remote > > protocol. This is something I intend to rectify with future patches > > but the ability to use gdb_sysroot like this is useful for attaching > > to processes running in chroot jails and containerized environments > > so I am submitting this series independently. > > What problem are you trying to fix? I'm mostly trying to eliminate the extra work users have to do in order to attach to remote processes or to attach to local processes running in containers. For remote processes you have to do something like: set sysroot remote: file /path/to/local/copy/of/binary target remote WHEREVER or: set sysroot /path/to/local/copy file /path/to/local/copy/of/binary target remote WHEREVER I would ideally like to get to the situation where the only command you need is "target remote ...", but a step in that direction is removing the required "file" command. For processes running in containers you have to do something like: set sysroot /proc/PID/root file /proc/PID/exe attach PID Again, I'd like to get to the situation where the only command you need is "attach PID". This series removes the need for the "file" command in this sequence, but you still need the "set sysroot". For the ultimate solution (removing the need for "set sysroot") Pedro suggested a new option, "set sysroot target:" that would be the default and would mean "if the target is remote, pull binaries over the remote protocol; if the target is local, grab them from the filesystem." There's details here: https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity Aside from removing the need for the user to set a sysroot for these two cases (where GDB has enough information to imply what the user is asking for) it unblocks multi-inferior debugging when different inferiors require different sysroots, something that can't be done right now. I don't think this is relevant for remote debugging right now as we only support one gdbserver connection at a time, but it is relevant for containers where you might need to debug, eg, a webserver in one container talking to a database server in another. I would also like to make it possible to fetch stripped debug info over the remote protocol if the user desires it, so that's something else I'm thinking about with this work. Cheers, Gary -- http://gbenson.net/