From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27494 invoked by alias); 13 Sep 2014 01:06:18 -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 27483 invoked by uid 89); 13 Sep 2014 01:06:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oi0-f73.google.com Received: from mail-oi0-f73.google.com (HELO mail-oi0-f73.google.com) (209.85.218.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 13 Sep 2014 01:06:16 +0000 Received: by mail-oi0-f73.google.com with SMTP id a141so62152oig.0 for ; Fri, 12 Sep 2014 18:06:14 -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=hujX6r/6mEGGgetHtoWUvsNp7c6PMU9jMaX075ihaws=; b=eK5Z09EQBcvAl4XuGbYBkNPZjvdoHD5G1mAhWpNdHT3e28MhhMtyT+tcSSQODJAomt tUfdDB6yKcHpT3wmy6CRWyeRBgzxJ9IM+PvVeOJxs06eQqkGsx3jw6RYqmP/BoF4dLVW QmVi+0SjKUd5w9vNUCfadx13NfnUuiNMAYR8DDvHCjerY8ts0oG+XYoQIFNKUc1Qje9T 1La7nor4N/aRpzxiwd8m+MFSJoXVt2xiMJMQyzJKv8KfFbNu+SHXekNrgn2GSLpsSSpj 4SwKpqhoec+o1uYlatnxmFeT0PTUfkWEpHqASjR7EjkgVevbWEhLkf55GbVFdEEo2S77 FryA== X-Gm-Message-State: ALoCoQlh8r+ryN/f5Lghoa59WKDCj0ZL+GYIQ1znUeyRQvBLmKkBDeP3+1BMxcoNM9ID4RXWTq6g78/7g6GiQBfZ9xZ96kBjBJxJThdqMsM2fi08G7JqrQp/EXCCDqpCWIw8/VYu9lBAYM/R9HCLkbgpNjQEIVfwn6FKQH1xHLDyAald8OoqMCU= X-Received: by 10.43.155.134 with SMTP id li6mr7245242icc.3.1410570373953; Fri, 12 Sep 2014 18:06:13 -0700 (PDT) Received: from corpmail-nozzle1-2.hot.corp.google.com ([100.108.1.103]) by gmr-mx.google.com with ESMTPS id t28si263434yhb.4.2014.09.12.18.06.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Sep 2014 18:06:13 -0700 (PDT) Received: from ruffy2.mtv.corp.google.com ([172.17.128.107]) by corpmail-nozzle1-2.hot.corp.google.com with ESMTP id cfaqcbJ8.1; Fri, 12 Sep 2014 18:06:13 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21523.39044.768702.981508@ruffy2.mtv.corp.google.com> Date: Sat, 13 Sep 2014 01:06:00 -0000 To: Pedro Alves Cc: Jan Kratochvil , "gdb-patches@sourceware.org" Subject: Re: time to workaround libc/13097 in fsf gdb? In-Reply-To: <5412E3AC.80203@redhat.com> References: <5411CFAE.7040805@redhat.com> <20140912115452.GA5626@host2.jankratochvil.net> <5412E3AC.80203@redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00474.txt.bz2 Pedro Alves writes: > On 09/12/2014 12:54 PM, Jan Kratochvil wrote: > > On Thu, 11 Sep 2014 18:37:02 +0200, Pedro Alves wrote: > >> Also, we know the address of the vDSO/gate (symfile-mem.c). Can't > >> we use that to match instead of the name? > > [...] > >> ISTR having seen a patch that does that, but I can't seem to find it. > > > > Re: [patch+7.5.1] Work around PR libc/13097 "linux-vdso.so.1" #3 > > https://sourceware.org/ml/gdb-patches/2012-11/msg00636.html > > Message-ID: <20121125181505.GA26194@host2.jankratochvil.net> > > > > It is pending/unreviewed/unapproved. > > Ah, yeah, I think that was it. > > I was more inclined to leave the vdso in the shared library list > though, like ldd does, than filtering it out. I like this too. No point in hiding it from the user. > 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. I'm not sure either. It *would* be nice to connect the processing of vdso when seen by svr4_read_so_list (called during shared library loading) with add_syscall_page (called as an observer when an inferior is created). The same file (vdso) is processed in two disparate places with no linkage for the human reader between them - a bit confusing. > > Also I am not sure it is really still an issue on latest upstream glibc, it is > > not an issue on Fedora 21 x86_64 glibc with the reproducer from: > > https://sourceware.org/bugzilla/show_bug.cgi?id=13097 > > > > (That is old Fedoras workarounded it in glibc, then some Fedoras exposed the > > issue in GDB but now it is not visible - so either Fedoras workaround it again > > or just upstream glibc switched/workarounds it also.) I downloaded glibc 2.20 and tested it with gdb 7.8. Still an issue. [I just did a simple build, if there's a configure option that will fix things I didn't try one.] I think FSF gdb 7.8[.1?] (the latest) should work with FSF glibc 2.20 (the latest).