From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24723 invoked by alias); 6 Oct 2003 19:57:05 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 24716 invoked from network); 6 Oct 2003 19:57:04 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 6 Oct 2003 19:57:04 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 386A7357B; Mon, 6 Oct 2003 12:57:03 -0700 (PDT) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.9/8.12.9) with ESMTP id h96Jv2N2030342; Mon, 6 Oct 2003 12:57:02 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id h96Jv1DV030338; Mon, 6 Oct 2003 12:57:01 -0700 Date: Mon, 06 Oct 2003 19:57:00 -0000 Message-Id: <200310061957.h96Jv1DV030338@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Jim Blandy Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [PATCH] add-symbol-file-from-memory command In-Reply-To: Daniel Jacobowitz's message of Monday, 6 October 2003 11:43:34 -0400 <20031006154334.GA25069@nevyn.them.org> X-Antipastobozoticataclysm: Bariumenemanilow X-SW-Source: 2003-10/txt/msg00119.txt.bz2 Dan is right on the money, as usual. As to why the entry point page was added on x86, correct: int $0x80 is the traditional Linux/x86 system call ABI and still works of course; newer x86 processors support "sysenter", which enters kernel mode without saving state in a normal trap frame and takes many fewer cycles than the normal trap path "int N" uses; AMD64 processors running 32-bit x86 code support "syscall", which is similarly cheaper and more constrained on the kernel side than a vanilla trap. (There is not at the moment a vsyscall DSO for native AMD64 processes. I may have said or implied there was, because that's what I'd been thinking. In fact, there is a kernel entry page in a different form that probably will need to be revamped into the same vsyscall DSO plan to support unwinding properly.) On the ia64 there is analogously a new and spiffier way to enter the kernel than the old "break" instruction (the generic trap requester instruction): it has a really cool feature, wherein there is an extra kind of permission bit in the page tables that permits code on that page to execute the magic "epc" instruction, which puts the processor in a special semiprivileged mode without the overhead of a normal trap into kernel mode, letting it access kernel memory and some other such things that might suffice for a given system call's implementation (and then return to normal user mode again) while never fully reloading some kinds of internal state a normal trap would do. I don't know enough about any other processor off hand to speculate whether a similar new generic kernel-entry mechanism might come in there. But, as Dan has pointed out, there are various system calls that can be optimized by implementing them in kernel-supplied code that runs purely in user mode (such techniques are well-travelled in research kernels); so it is reasonable to speculate that such a DSO might one day be use on any given machine. Dan is also correct in his identification of the portability issues. The auxv arrangement, including NT_AUXV and /proc/*/auxv, is common to almost every ELF-based Unix-like platform; the stack layout (not the access methods AFAIK) is part of every SVR4 ABI spec, though not strictly within the purview of the ELF format spec itself. (AFAIK only GNU/Hurd doesn't use AT_*. Though AFAIK only Linux 2.6 and Solaris support NT_AUXV and /proc/*/auxv, I am not aware of any system providing a different interface for getting that information; i.e. things support those or nothing.) However, the AT_* values (except for AT_NULL==0) are neither standardized nor de facto reliably the same across operating systems (they are part of the SVR4 ABI spec for each processor I believe). The values in include/elf/common.h are copied from glibc's , and are what GNU/Linux uses. Some of the values used on Solaris conflict, though Sun seems to have taken to using AT_SUN_* names and values >=2000 for recent additions and so it now seems unlikely they will use values 32 or 33 and thus risk false matches with the Linux AT_SYSINFO_EHDR tag. (FYI, NetBSD's elf.h header has all of Sun's values and no GNU/Linux values; however NetBSD itself uses only the tags <10 which in fact match exactly everywhere.) So the actual call checking for AT_SYSINFO_EHDR belongs in linux-tdep (and added separately to other OS-tdep's if any other systems follow suit). But there's no reason the code that does the real work shouldn't be in shared or generic ELF-specific places so that the OS-tdep portion is just a line or two. The add-symbol-file-from-memory command is the larger chunk of that work. Its extant implementation is ELF-specific, but the notion is not; so, consistent with other gdb features, it would make sense for the command to exist but fail with "not supported on this target" for non-ELF targets. Where the other part of the work (AT_SYSINFO_EHDR checking) belongs we can pick up in the other thread, which is where this message really belonged too. Thanks, Roland