Re: -static-libstdc++ breaks building gdb

[Mike Stump <mikestump@comcast.net>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 9068 bytes --]

On Sep 3, 2013, at 2:39 PM, Mike Stump <mikestump@comcast.net> wrote:
> I'm on a openSUSE 11.4 system with a:
> 
> gcc (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585]
> 
> host compiler.  When I building gdb trunk, I get a failure to build because 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 diagnostic:

gcc: unrecognized option '-static-libstdc++'

was necessary to fix to get the link to not fail.  I was wrong.  It is however, unsightly.
From gdb-patches-return-104969-listarch-gdb-patches=sources.redhat.com@sourceware.org Tue Sep 03 22:01:16 2013
Return-Path: <gdb-patches-return-104969-listarch-gdb-patches=sources.redhat.com@sourceware.org>
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: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
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 <gdb-patches@sourceware.org>; Tue, 03 Sep 2013 15:01:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d\x1e100.net; s 130820;        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®S128-SHA bits\x128/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 <dje@google.com>
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 <jan.kratochvil@redhat.com>
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 <jan.kratochvil@redhat.com>
 > 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.