From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25933 invoked by alias); 7 Mar 2013 13:36:25 -0000 Received: (qmail 25840 invoked by uid 22791); 7 Mar 2013 13:36:23 -0000 X-SWARE-Spam-Status: No, hits=-8.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 Mar 2013 13:36:11 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r27Da9Wn006273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Mar 2013 08:36:09 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r27Da889015153; Thu, 7 Mar 2013 08:36:08 -0500 Message-ID: <513897C7.1060709@redhat.com> Date: Thu, 07 Mar 2013 13:36:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: Jan Kratochvil CC: Doug Evans , gdb-patches Subject: Re: [patch+doc 1/2] filename-display: 1->4 options {inferior,libs}{,-sepdebug} References: <20130215202536.GA20435@host2.jankratochvil.net> <20130227185345.GA21375@host2.jankratochvil.net> <20130227195251.GA29891@host2.jankratochvil.net> <51386C1C.3060107@redhat.com> <20130307120407.GA21059@host2.jankratochvil.net> In-Reply-To: <20130307120407.GA21059@host2.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2013-03/txt/msg00285.txt.bz2 On 03/07/2013 12:04 PM, Jan Kratochvil wrote: > On Thu, 07 Mar 2013 11:29:48 +0100, Pedro Alves wrote: >> On 03/06/2013 07:54 PM, Doug Evans wrote: >>> We have various parameters that together specify where to find separate debug info. >>> Is it possible to piggyback on that? >>> E.g., Something minimal for now like specifying which ones are >>> displayed as relative with the default being none? >> >> I've not really been following the discussion closely, but >> I was also wondering the same. The ultimate goal seems to be to >> detect system vs non-system binaries ("system" is the word used >> in the new proposed knobs even). Isn't the definitive answer >> making GDB consider files under "/usr/" >> system binaries (the --prefix by default, but could be somewhere >> else, thus should be tunable), and everything else, non-system? > > Besides /usr you need also /bin, /lib, /lib64, /libx32, /opt etc. etc. True, though I don't think there's much more than that. > I was thinking rather about the opposite way, consider non-system binaries > those that are under /usr/local, /root and /home . The set of system paths is defined by the OS integrator, so seemed closer to being bounded to me. The user can well put files wherever it wants. Other components "know" paths in the system as well, like gcc with the system includes and the native lib dir paths, or even the linker and the loader. Note these tools usually think of /usr/local as "system", and I'd think for this case that apply too. Irrespective of glass half empty vs half full, I guess the first question is whether by-path is a better approach than by have-sep-debug. It _feels_ more to the point, therefore better to me, but I'm not really trying to impose it or block the other approach. I wonder what others think. > But that is all non-trivial number of directories which will never catch all > the distros/setups out there. Using sepdebug for system/non-system also feels like will always have corner cases, though. -- Pedro Alves