From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24403 invoked by alias); 19 Aug 2016 11:41:02 -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 24391 invoked by uid 89); 19 Aug 2016 11:41:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-oi0-f53.google.com Received: from mail-oi0-f53.google.com (HELO mail-oi0-f53.google.com) (209.85.218.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 Aug 2016 11:41:00 +0000 Received: by mail-oi0-f53.google.com with SMTP id f189so59541125oig.3 for ; Fri, 19 Aug 2016 04:40:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kFrPeJHL/n6+UT5z7ikiN2IHZmWunxRp7NvZSQ9bYlM=; b=FOb2Pn6ERxUukHa9E1ti8HfAPegIlc6dC3sJAu1CgLzCrEnYrlOj+NCPu/MWyrTydr YYt0t5U/W45hQTE724rE4Rz3ChPkmBGBgBXfSOJoVO51Pdan5E71oCZnnkxFF8ioDMMw RqGUNbv1hlsJflzsmuGZgi9u57GyaDWwplYnstSUuTanEUg0+LTTY1KgXUbLPe3pAgi1 lC/4njpAgAHsyEzwIwLxbKPqz1ld2+pUX7lba6IDeXm2KI2RcTETfRMy3TvDegN1dntD iddLDwCC+EyoJ0dzXepDRliQjTr7GMohEaJn2/5VQ40R1u4WmgGhzRxn6SrCAKZiUjVz gbXA== X-Gm-Message-State: AEkoouutBa8/N7uc1z/gD85uHck9QKtmS73Xb3TVfMG4rBKpNHTbC33+B8CEt2QzeRQiCaxanFW4T1UwQpehBQ== X-Received: by 10.202.240.4 with SMTP id o4mr4084748oih.198.1471606858592; Fri, 19 Aug 2016 04:40:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.207.201 with HTTP; Fri, 19 Aug 2016 04:40:58 -0700 (PDT) In-Reply-To: References: <86twercyuv.fsf@gmail.com> <89b5bdc8-0be2-538e-3932-1f5d4a1bc1e8@redhat.com> <86eg5ucmcv.fsf@gmail.com> <96141d5a-3384-8314-1274-d1348dafe0c5@redhat.com> <86twehaxl3.fsf@gmail.com> From: Yao Qi Date: Fri, 19 Aug 2016 11:41:00 -0000 Message-ID: Subject: Re: warning: Could not load shared library symbols for linux-vdso.so.1. To: Pedro Alves Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00198.txt.bz2 On Fri, Aug 19, 2016 at 11:32 AM, Pedro Alves wrote: >> >> They are good to me. Do you plan to push them to 7.12 branch? > > I was working under the assumption you wanted it in 7.12, given > you set the milestone. :-) > I put this issue there to make sure we don't forget this one. At that mome= nt, I didn't expect a big change. :) > > However, if you want this on 7.12, then there's another option. We > can start with the hacky version that moves the add_vsyscall_page > call to gdbarch_vsyscall_range, as mentioned in: > >> Now, in order to do this, we need to move the add_vsyscall_page >> call earlier, before svr4_current_dsos is ever called, in order >> to read the vdso bfd out of memory before we ever first need to >> filter out the vdso. The cleanest I could do with the current >> gdbarch_vsyscall_range-based design was to do the add_vsyscall_page >> call from within gdbarch_vsyscall_range. But that looks very ugly >> to me, for reading symbols from a quite innocent looking gdbarch hook. > > and then clean this up with the new linux_so_ops, on master, only. OK, that is fine. > > So below's the "ugly" patch. It's functionally exactly the same as > the larger one. The switch to linux_so_ops was mainly "cosmetic". > > Let me know what you prefer. > This patch is good to master and 7.12. --=20 Yao (=E9=BD=90=E5=B0=A7)