From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4190 invoked by alias); 3 Sep 2013 21:54:19 -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 4134 invoked by uid 89); 3 Sep 2013 21:54:19 -0000 Received: from qmta05.emeryville.ca.mail.comcast.net (HELO qmta05.emeryville.ca.mail.comcast.net) (76.96.30.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Sep 2013 21:54:19 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RDNS_NONE,SPF_PASS autolearn=no version=3.3.2 X-HELO: qmta05.emeryville.ca.mail.comcast.net Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta05.emeryville.ca.mail.comcast.net with comcast id LiVG1m0010FhH24A5luHkc; Tue, 03 Sep 2013 21:54:17 +0000 Received: from up.mrs.kithrup.com ([24.4.193.8]) by omta08.emeryville.ca.mail.comcast.net with comcast id LluG1m00W0BKwT48UluGUW; Tue, 03 Sep 2013 21:54:17 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: -static-libstdc++ breaks building gdb From: Mike Stump In-Reply-To: Date: Tue, 03 Sep 2013 21:54:00 -0000 Cc: Eric Botcazou Content-Transfer-Encoding: quoted-printable Message-Id: <1EF8DBB8-8A02-4A2F-BA7C-15172D9C614B@comcast.net> References: To: "gcc-patches@gcc.gnu.org Patches" , "gdb-patches@sourceware.org" X-SW-Source: 2013-09/txt/msg00113.txt.bz2 On Sep 3, 2013, at 2:39 PM, Mike Stump wrote: > I'm on a openSUSE 11.4 system with a: >=20 > gcc (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585] >=20 > host compiler. When I building gdb trunk, I get a failure to build becau= se configure tests g++ to see if these work, but gdb links with gcc and 4.5= .1 errors out with the flag. You can't set LDFLAGS, because that is given = to gcc, without testing the flag with gcc. Hum, I was confused by other build errors. I was assuming that the diagnos= tic: gcc: unrecognized option '-static-libstdc++' was necessary to fix to get the link to not fail. I was wrong. It is howe= ver, unsightly. >From gdb-patches-return-104969-listarch-gdb-patches=sources.redhat.com@sourceware.org Tue Sep 03 22:01:16 2013 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 12356 invoked by alias); 3 Sep 2013 22:01:16 -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 Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 12343 invoked by uid 89); 3 Sep 2013 22:01:15 -0000 Received: from mail-ve0-f201.google.com (HELO mail-ve0-f201.google.com) (209.85.128.201) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 03 Sep 2013 22:01:15 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD,SPF_SOFTFAIL autolearn=ham version=3.3.2 X-HELO: mail-ve0-f201.google.com Received: by mail-ve0-f201.google.com with SMTP id m1so643414ves.0 for ; Tue, 03 Sep 2013 15:01:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:content-type :content-transfer-encoding:message-id:date:to:cc:subject:in-reply-to :references; bh=LiTFyDvS0fWBsxgUDkhOGd6LDJ9qhlXqT9PqhCEI4wM=; b=Ct0J8WdS/bJzIE4uXvDLTXc6/8cHFDrsczhqi/5cJC6kgHNlO1ZjDLr3XrPSZYGDeh yAcWBbKn7qAgJiYo7/3mIAwQ7vXyYkthINCB6hOolBvee+6h6BN+vLPMrCWA61l3tOAO fE1W1HtoIBjH62jo/4rfwJP/Gh8gwFbUlLB9hA9kTngqsKhIaJmiuxl94wyOvKa6XM0t kMFiR+Se6C3PfeIdfVc/0JFYJT61ovvf44PRgLV1ACZdEjJdc9rYdfZ0BKXS5U0iyilh bDF5MTB69UO3Ko1Zgc1STlQMj0Mkk3vhfwyVvnQIMLP8TDc/jyLKmnEpIGLiPwCwnjpD B6yg== X-Gm-Message-State: ALoCoQknTm62eqBeGXaLjYlvEWbcGtZBvb2twOvFBHwt+zPztGfuCJ85fd0H8Ngc0NerLGr+WPE+TczIJ9Ogt453Dm1VdOTsI9tVgCd+HGG80nGNYaii9qGSggdbVYYFy5dhLnzAs0UKG5J+y8GUZCiRZqYRJI00IfEM4bDpuzrsuxnmZg3f7C4XLLN2fCdms6FCcVkaMIQmbpmXLqn10JqBLVK1XRR3Ig== X-Received: by 10.236.147.70 with SMTP id s46mr11243838yhj.0.1378245670981; Tue, 03 Sep 2013 15:01:10 -0700 (PDT) Received: from corp2gmr1-1.hot.corp.google.com (corp2gmr1-1.hot.corp.google.com [172.24.189.92]) by gmr-mx.google.com with ESMTPS id h70si1047945yhk.2.1969.12.31.16.00.00 (version=TLSv1.1 cipher=AES128-SHA bits=128/128); Tue, 03 Sep 2013 15:01:10 -0700 (PDT) Received: from ruffy.mtv.corp.google.com (ruffy.mtv.corp.google.com [172.17.128.44]) by corp2gmr1-1.hot.corp.google.com (Postfix) with ESMTP id 533E731C1EC; Tue, 3 Sep 2013 15:01:10 -0700 (PDT) From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21030.23589.767143.370565@ruffy.mtv.corp.google.com> Date: Tue, 03 Sep 2013 22:01:00 -0000 To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [patch 0/3] Support .dwp with the name of symlinked binary file In-Reply-To: <20130828160529.GA23977@host2.jankratochvil.net> References: <20130828160529.GA23977@host2.jankratochvil.net> X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00114.txt.bz2 Content-length: 4661 Jan Kratochvil writes: > Hi Doug, > > this patch is made upon Doug's request where they use this case: > $ ../gdb gdb.base/start-symlink > gdb.base/start* > gdb.base/start-symlink -> start* > gdb.base/start-symlink.dwp More specifically, bin/start -> /foo/abc/def bin/start.dwp -> /foo/ghi/jkl > I was proposing to symlink also all .dwp files in such case, for example > Fedora symlinks all .debug files - but Doug did not accept that: > -rwxr-xr-x 1 root root 92560 Feb 19 2013 /lib64/libz.so.1.2.7* > lrwxrwxrwx 1 root root 13 Aug 19 07:32 /lib64/libz.so.1 -> libz.so.1.2.7* > -r--r--r-- 1 root root 167247 Feb 19 2013 /usr/lib/debug/lib64/libz.so.1.2.7.debug > lrwxrwxrwx 1 root root 19 Aug 19 08:03 /usr/lib/debug/lib64/libz.so.1.debug -> libz.so.1.2.7.debug I couldn't use it because I can't change what's provided to gdb. There's an underlying abstraction layer implemented with symlinks, and there's not necessarily a useful relationship between what's above the boundary and what's below it. > This patchset depends on: > Re: [patch] [7.6.1] Fix argv[0] symlink regression (PR 15415) > https://sourceware.org/ml/gdb-patches/2013-08/msg00789.html > Message-ID: <20130827140915.GA17861@host2.jankratochvil.net> > > > GDB 7.6 got .dwp support > (I have tested c2f14511388ab029f3bda0f5227eab67e04daac5) > and it worked for: > $ ../gdb gdb.base/start-symlink > gdb.base/start* > gdb.base/start-symlink -> start* > gdb.base/start-symlink.dwp > although it did not work for: > $ ../gdb gdb.base/start-symlink > gdb.base/start* > gdb.base/start-symlink -> start* > gdb.base/start.dwp > > Then there was a patch: > commit bfacf227ec8ee6b1c73311e323bd93c1eddd9ca6 > Author: Jan Kratochvil > Date: Sun Feb 3 15:54:14 2013 +0000 > Replace xfullpath calls by gdb_realpath calls. > > and the functionality has reversed, it no longer worked for: > $ ../gdb gdb.base/start-symlink > gdb.base/start* > gdb.base/start-symlink -> start* > gdb.base/start-symlink.dwp > while it started to work for: > $ ../gdb gdb.base/start-symlink > gdb.base/start* > gdb.base/start-symlink -> start* > gdb.base/start.dwp > > This issue affects only DWP due to > dwarf2read.c:open_and_init_dwp_file(): > dwp_name = xstrprintf ("%s.dwp", dwarf2_per_objfile->objfile->name); > > and it does not affect .debug files as their filename is stored in > .gnu_debuglink. > > This patchset can be considered as an extension of the existing released FSF > GDB 7.6 DWP functionality, it is not fixing any FSF release regression as > GDB 7.5 did not have DWP support. > > With xfullpath before the BFD cache was less efficient (cache misses for > symlinked files with different basename). Nowadays with gdb_realpath one > cannot undo it, therefore I have moved the gdb_realpath() call from openp() to > gdb_bfd_open() so that GDB code still knows the original filename before > gdb_realpath(). > > This patch has negative performance impact: (1) openp() is called less times > than gdb_bfd_open() so gdb_realpath() will be now called in more cases. > (2) As gdb_realpath() call is left in most of the openp() calls (due to > OPF_RETURN_REALPATH set there) gdb_realpath() will be now called twice. > These cases could be optimized, see /home/user/file below. For reference sake, several instances that could measurably impact performance (because there can be a lot of them in one session, e.g., solibs, fission dwo files) call openp and pass the descriptor to gdb_bfd_open. Calling openp for dwo files doesn't need realpath. Can we remove OPF_RETURN_REALPATH when doing openp (solib) ? [ref: solib_find] We kind of have to to fix the dwp problem for solibs. > IMO the real problem is that gdb_realpath() is currently written very > ineffectively. It could cache most of the stat() results even for different > filenames as most of their parent directories are the same. Such optimization > is not in this patchset. Right. I know of at least one implementation of this optimization. I'm not sure what the status of it is, but it's easy enough to do over. > In fact all the gdb_realpath() calls are IMO a bug, it is more convenient to > see I am debugging /home/user/file than to see it is /.sdb5/home/user/file > (due to common 'ln -s .sdb5/home /home' joining of partitions etc.). > As this goes against some GDB goal I do not understand I have not changed it > everywhere yet. Still the [patch 3/3] already makes such change for objfiles > and exec file, such as in "info files" (but not for source files). Agreed.