From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12724 invoked by alias); 6 Oct 2003 15:43:36 -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 12716 invoked from network); 6 Oct 2003 15:43:35 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 6 Oct 2003 15:43:35 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A6XWI-0006Xx-Jp; Mon, 06 Oct 2003 11:43:34 -0400 Date: Mon, 06 Oct 2003 15:43:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Roland McGrath , gdb-patches@sources.redhat.com Subject: Re: [PATCH] add-symbol-file-from-memory command Message-ID: <20031006154334.GA25069@nevyn.them.org> Mail-Followup-To: Jim Blandy , Roland McGrath , gdb-patches@sources.redhat.com References: <200310030427.h934REdK018487@magilla.sf.frob.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00102.txt.bz2 On Mon, Oct 06, 2003 at 10:29:05AM -0500, Jim Blandy wrote: > > It seems I'm confused about where the vsyscall support is useful. I > thought it was Linux-specific, but folks disagreed. I think it's > important to get this right, because that determines where the code > goes in GDB and what the interfaces are. No, I agree with you that vsyscalls are Linux-specific - for now at least. But I think that the concept of add-symbol-file-from-memory is well separated from the concept of vsyscalls. It seems like a useful thing to have for interacting with, say, a hypothetical minimalist ELF shared loader. > (This message rambles in a whiney sort of way, and then asks specific > questions at bottom.) > > One of the sources of my confusion is whether it's Linux-specific or > ELF-specific. The vsyscall DSO only appears on Linux --- at the > moment. But supporting it in GDB can be done without reference to > anything Linux-specific: you need to check the auxilliary vector (an > ELF thing) and read an ELF file out of memory. It never makes > Linux-specific system calls, or relies on Linux-specific filesystem > layout stuff, for example. So leaving linux-tdep.c and > config/nm-linux.h out of the picture entirely, and doing everything as > ELF-related code, will not introduce any interface violations. Except that the AT_SYSINFO tag is really Linux-specific. There's no guarantee that nothing else would use the same auxv tag for something else. I don't believe they're centrally registered, since they're ultimately system-specific by nature. > But although I understand that the Linux system call interface is > changing, and that the new interface requires the kernel to provide > unwinding information, because the old way of unwinding from system > calls no longer works, I've never understood why the system call > interface had to change in the first place. > > In a sense, it's irrelevant --- the interface *is* changing, and GDB > must continue to work. But not understanding why the system call > interface must change makes it difficult for me to assess how likely > other systems are to adopt vsyscall DSO's, and thus whether it's > better to isolate the additional complexity to Linux-specific files, > even though the work is portable to all ELF targets, or whether it's > better to make it ELF-specific, to make it easy (or unnecessary) to > adapt GDB when the feature appears elsewhere. > > I think there's a good argument that one should simply always > implement everything using the smallest interface you can stand, even > if it's only used in a specific situation, because it makes the code > easier to reuse. Since the vsyscall DSO support only really depends > on ELF stuff, and it automatically detects when it's needed (by the > presence of a specific element in the auxilliary vector), maybe that's > the best thing to do. > > > So, why did the kernel system call interface need to change? How > likely are other Unices to begin using vsyscall DSO's? I've seen > x86-64 and IA-64 mentioned; would it be useful on PPC and the S/390, > too? (Just to pick random architectures out of the air.) This is all "as I understand it". Feel free to correct, anyone. The original motivation for x86 was that we have three different mechanisms for making a syscall: - int $80 - sysenter - syscall It turns out that int $80 isn't the best way any more, on some processors. sysenter (?) is much faster. But changing the syscall interface is something that has to be done very delicately.... so the "new" way of doing syscalls isn't using sysenter, which wouldn't work everywhere etc. It's "jump to this address in a preloaded DSO, on a kernel-mapped high memory page". It's simple, powerful, extensible. The kernel can do other neat things with it too. For ia64 there's been discussion of lightweight syscalls which can be implemented entirely within that page. Gettimeofday is the best example. I think there are some synchronization etc. issues with this (plus you lose strace ability if you're not careful!) so it hasn't been done yet. And this page can also be used for signal trampolines, and is on some architectures. Which is a beauteous and wonderful thing, because it can provide DWARF-2 CFI information for the signal trampoline. I suspect at least the signal trampolines and lightweight syscalls could be useful on other architectures also. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer