From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31461 invoked by alias); 7 Oct 2003 23:32:09 -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 31451 invoked from network); 7 Oct 2003 23:32:08 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 7 Oct 2003 23:32:08 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h97NW7103695 for ; Tue, 7 Oct 2003 19:32:08 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h97NW6D13260; Tue, 7 Oct 2003 19:32:06 -0400 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h97NW6w10369; Tue, 7 Oct 2003 16:32:06 -0700 Message-ID: <3F834CF5.2080204@redhat.com> Date: Tue, 07 Oct 2003 23:32:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz CC: Jim Blandy , Roland McGrath , gdb-patches@sources.redhat.com Subject: Re: [PATCH] add-symbol-file-from-memory command References: <200310030427.h934REdK018487@magilla.sf.frob.com> <20031006154334.GA25069@nevyn.them.org> In-Reply-To: <20031006154334.GA25069@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00182.txt.bz2 Daniel Jacobowitz wrote: > 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. > So, coming late to the discussion, is it fair to summarize that a consensus is emerging that this is good and needful functionality, which should go into gdb, pending only the resolution of a few naming and placement issues?