From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7108 invoked by alias); 6 Oct 2003 15:30:16 -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 7097 invoked from network); 6 Oct 2003 15:30:15 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 6 Oct 2003 15:30:15 -0000 Received: by zenia.home (Postfix, from userid 5433) id 1819820766; Mon, 6 Oct 2003 10:29:05 -0500 (EST) To: Roland McGrath Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [PATCH] add-symbol-file-from-memory command References: <200310030427.h934REdK018487@magilla.sf.frob.com> From: Jim Blandy Date: Mon, 06 Oct 2003 15:30:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00100.txt.bz2 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. (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. 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.)