From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12469 invoked by alias); 17 Jun 2003 20:41:03 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 29999 invoked from network); 17 Jun 2003 20:34:29 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 17 Jun 2003 20:34:29 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8BD472B5F; Tue, 17 Jun 2003 16:34:27 -0400 (EDT) Message-ID: <3EEF7B53.1020108@redhat.com> Date: Tue, 17 Jun 2003 20:41:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: davidm@hpl.hp.com Cc: Nick Clifton , davidm@napali.hpl.hp.com, gdb@sources.redhat.com, binutils@sources.redhat.com, roland@redhat.com Subject: Re: [davidm@napali.hpl.hp.com: readelf question] References: <20030613145520.GA2930@lucon.org> <16111.25674.965375.967286@napali.hpl.hp.com> <3EEF6B6B.3020308@redhat.com> <16111.30389.189801.925393@napali.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00353.txt.bz2 > On Tue, 17 Jun 2003 15:26:35 -0400, Andrew Cagney said: > > > Andrew> David, I'm guessing that ``gate page'' is vsyscall page? > > Yes. To be precise: on ia64, the gate page serves a similar purpose > as on x86 the vsyscall page. (ia64 linux doesn't actually support > virtual syscalls; instead, there are lightweight syscalls, which have > similar performance but aren't restricted to user-mode execution). > > Andrew> Whats the Linux kernel status on this one? > > They're in the 2.5 tree now (both on x86 and ia64). Ya! Signs of sanity! Shame no one thought to mention that here :-( > Andrew> Last I heard was a kernel patch to make auxv info available > Andrew> in the core file, and via the /proc and ptrace interfaces. > > Yes: auxv, core, and ptrace are there. I don't think /proc support is > there. Not sure if Roland is planning to do something about that. I think it was in the patch? > Andrew> Thing is, if that's done, those extra memory sections can go > Andrew> back to being extra memory sections (and everything becomes > Andrew> much simpler). > > I don't have much of a preference myself. I'm sure Roland has thought > much more about the user-level parts of the support than I have > (though I do like the idea of being able to get symbol and library > info for the kernel DSO(s); not sure how you'd do that with plain > memory sections). The discussion is in the archives. The auxv provides the address of the start of vsyscall page. GDB can then use that to fudge up a bfd describing those memory contents. This has several important properties: - GDB always uses the AUXV address. That way GDB uses a single consistent and robust mechanism on both core files and live processes. - GDB needs the AUXV anyway. With out it, GDB would be forced to rely on heuristics when trying to determine the address of the vsyscall page in an already running process (it can't trust the stack). So, while at first sight, having the core headers describe the syscall page symbol tables appears useful, it turns out to be less so. Should it be pulled? Andrew