From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3898 invoked by alias); 12 Sep 2014 12:33:28 -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 3888 invoked by uid 89); 12 Sep 2014 12:33:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS 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; Fri, 12 Sep 2014 12:33:26 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8CCXOZs019399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 12 Sep 2014 08:33:24 -0400 Received: from host2.jankratochvil.net (ovpn-116-53.ams2.redhat.com [10.36.116.53]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8CCXKNM014889 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Fri, 12 Sep 2014 08:33:23 -0400 Date: Fri, 12 Sep 2014 12:33:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: Doug Evans , "gdb-patches@sourceware.org" Subject: Re: time to workaround libc/13097 in fsf gdb? Message-ID: <20140912123320.GA8704@host2.jankratochvil.net> References: <5411CFAE.7040805@redhat.com> <20140912115452.GA5626@host2.jankratochvil.net> <5412E3AC.80203@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5412E3AC.80203@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00399.txt.bz2 On Fri, 12 Sep 2014 14:14:36 +0200, Pedro Alves wrote: > I was more inclined to leave the vdso in the shared library list > though, like ldd does, than filtering it out. Like, similar to > your gdbarch_solib_file_not_found_is_ok patch, but look at the > addresses rather than filenames in the hook. I'm not sure > whether that'd complicate things too much. Everything can be done but this is again changing a direction/behavior of GDB upon receiving a fix of current behavior. So far GDB has not been including vDSO in the library list and the patch was fixing that behavior. One can go very far from doing one fix up to rewriting GDB from scratch. Jan