From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-43119-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 14975 invoked by alias); 13 Mar 2014 15:04:37 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Received: (qmail 14956 invoked by uid 89); 13 Mar 2014 15:04:36 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,MISSING_HEADERS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2
X-Spam-User: qpsmtpd, 2 recipients
X-HELO: mail-we0-f179.google.com
Received: from mail-we0-f179.google.com (HELO mail-we0-f179.google.com) (74.125.82.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 13 Mar 2014 15:04:35 +0000
Received: by mail-we0-f179.google.com with SMTP id x48so980624wes.10        for <multiple recipients>; Thu, 13 Mar 2014 08:04:32 -0700 (PDT)
X-Received: by 10.194.174.197 with SMTP id bu5mr1646946wjc.71.1394723070512;        Thu, 13 Mar 2014 08:04:30 -0700 (PDT)
Received: from [192.168.0.102] ([2.83.161.167])        by mx.google.com with ESMTPSA id 19sm6277871wjy.17.2014.03.13.08.04.28        for <multiple recipients>        (version=TLSv1 cipher=RC4-SHA bits=128/128);        Thu, 13 Mar 2014 08:04:29 -0700 (PDT)
Message-ID: <5321C8FA.40708@gmail.com>
Date: Thu, 13 Mar 2014 15:04:00 -0000
From: Pedro Alves <alves.ped@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
CC: Mark Wielaard <mjw@redhat.com>, Cary Coutant <ccoutant@google.com>,  Doug Evans <dje@google.com>, "Metzger, Markus T" <markus.t.metzger@intel.com>,  "gdb@sourceware.org" <gdb@sourceware.org>, "binutils@sourceware.org" <binutils@sourceware.org>
Subject: Re: vdso handling
References: <A78C989F6D9628469189715575E55B230AA884EB@IRSMSX104.ger.corp.intel.com> <20140312071701.GW26922@bubble.grove.modra.org> <CADPb22SAmK5JB3muW_nCvuHN5L-aOcdyzYNR+OtnM3bA1x_OJg@mail.gmail.com> <CAHACq4o=HmdCo1FPFL-96raf2UN805jvM=VZM-9dbKrmzJFJTw@mail.gmail.com> <20140313010147.GZ26922@bubble.grove.modra.org> <1394704336.11818.115.camel@bordewijk.wildebeest.org> <20140313130322.GA3384@bubble.grove.modra.org> <5321C7C8.6000707@redhat.com>
In-Reply-To: <5321C7C8.6000707@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
X-SW-Source: 2014-03/txt/msg00036.txt.bz2

On 03/13/2014 02:59 PM, Pedro Alves wrote:

> Hmm.  How so?  On x86 (arch/x86/vdso/vdso.S), the kernel just does:

Hmm, guess I should really be looking at where the vdso is
actually mapped to a process's address space...  (no idea where
that is).

-- 
Pedro Alves