From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12951 invoked by alias); 20 Sep 2013 17:00:15 -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 12915 invoked by uid 89); 20 Sep 2013 17:00:15 -0000 Received: from e06smtp17.uk.ibm.com (HELO e06smtp17.uk.ibm.com) (195.75.94.113) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 20 Sep 2013 17:00:15 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp17.uk.ibm.com Received: from /spool/local by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 20 Sep 2013 18:00:10 +0100 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp17.uk.ibm.com (192.168.101.147) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 20 Sep 2013 18:00:09 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id BFACB219005A for ; Fri, 20 Sep 2013 18:00:08 +0100 (BST) Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by b06cxnps3075.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r8KGxuNh64815146 for ; Fri, 20 Sep 2013 16:59:56 GMT Received: from d06av10.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r8KH07oP032577 for ; Fri, 20 Sep 2013 11:00:08 -0600 Received: from br87z6lw.de.ibm.com (dyn-9-152-212-143.boeblingen.de.ibm.com [9.152.212.143]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id r8KH07bS032556; Fri, 20 Sep 2013 11:00:07 -0600 From: Andreas Arnez To: Jan Kratochvil Cc: gdb-patches@sourceware.org, Andreas Krebbel Subject: Re: [PATCH] Skip VDSO when reading SO list References: <87d2p9oi4i.fsf@br87z6lw.de.ibm.com> <20130920131549.GA18629@host2.jankratochvil.net> Date: Fri, 20 Sep 2013 17:00:00 -0000 In-Reply-To: <20130920131549.GA18629@host2.jankratochvil.net> (Jan Kratochvil's message of "Fri, 20 Sep 2013 15:15:49 +0200") Message-ID: <87siwzpgx4.fsf@br87z6lw.de.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13092017-0542-0000-0000-000006845D61 X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00771.txt.bz2 Thanks for the comments! Jan Kratochvil writes: > On Mon, 19 Aug 2013 16:44:13 +0200, Andreas Arnez wrote: >> 2013-08-19 Andreas Arnez >> >> * solib-svr4.c (svr4_read_so_list): Skip the VDSO when reading > vDSO OK, will replace all occurrences of 'VDSO' by 'vDSO'. >> link map entries. > > Could you include here the testcase from: > http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-core-open-vdso-warning.patch Sure. >> Index: gdb/gdb/solib-svr4.c >> =================================================================== >> --- gdb.orig/gdb/solib-svr4.c >> +++ gdb/gdb/solib-svr4.c >> @@ -1310,6 +1310,7 @@ static int >> svr4_read_so_list (CORE_ADDR lm, CORE_ADDR prev_lm, >> struct so_list ***link_ptr_ptr, int ignore_first) >> { >> + struct so_list *first = NULL; >> CORE_ADDR next_lm; >> >> for (; lm != 0; prev_lm = lm, lm = next_lm) >> @@ -1349,10 +1350,22 @@ svr4_read_so_list (CORE_ADDR lm, CORE_AD >> { >> struct svr4_info *info = get_svr4_info (); >> >> + first = new; >> info->main_lm_addr = new->lm_info->lm_addr; >> do_cleanups (old_chain); >> continue; >> } >> + >> + /* The l_name of a VDSO sometimes lies in read-only memory that > vDSO >> + is excluded from a core dump. In order to avoid the "can't >> + read pathname" warning, we try to identify the VDSO. One > vDSO >> + criteria is that the l_name address matches that of the main >> + executable. */ >> + if (first && new->lm_info->l_name == first->lm_info->l_name) > > Here should be also '&& ignore_first'. Hm, this shouldn't be necessary, because 'first' is only set when 'ignore_first' is set. Or did I miss something? >> + { >> + do_cleanups (old_chain); >> + continue; >> + } > > And move this block below so that the condition is evaluated only if > target_read_string has really failed. > > The purpose is that no workarounds should complicate the code in the case the > system components are already bug-free (after glibc gets fixed). That's a good point. Still, after thinking about this some more, I prefer the order in the original patch, because it prevents a bogus l_name from being detected in a second scan when the core dump is debugged on a system with a different glibc version. Users may also experience this after a glibc update. Thoughts?