From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24046 invoked by alias); 3 Oct 2003 21:41:53 -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 23990 invoked from network); 3 Oct 2003 21:41:52 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 3 Oct 2003 21:41:52 -0000 Received: by zenia.home (Postfix, from userid 5433) id 3437620766; Fri, 3 Oct 2003 16:41:41 -0500 (EST) To: Roland McGrath Cc: Mark Kettenis , Kevin Buettner , Daniel Jacobowitz , Andreas Schwab , Scott Bambrough , 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: Fri, 03 Oct 2003 21:41:00 -0000 In-Reply-To: <200310030427.h934REdK018487@magilla.sf.frob.com> 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/msg00061.txt.bz2 Roland McGrath writes: > I posted this originally back in May, and got no response whatsoever. I've > updated the patch to work with current mainline gdb and tested it again. I > hope there will be some response this time. This new user command is not > important, but this code needs review as it will form part of the support > for backtraces from system calls to work on Linux 2.6 kernels. This is important thing to get right; I'm sorry it wasn't reviewed promptly back in May. > This adds a user command add-symbol-file-from-memory, which is like > add-symbol-file but takes just the address of an ELF header in inferior > memory (and no other args) instead of a file name. > > This command may not really be worth having, but it serves to exercise the > underlying function symbol_file_add_from_memory. That function does the > work of reading symbols and unwind info from the Linux vsyscall DSO. > So please examine that new code. > > This makes symfile.c call bfd_elf_bfd_from_remote_memory, which is > implemented in bfd/elf.c and so won't exist if there is no ELF target > backend configured into libbfd. I couldn't see any obvious place in gdb > that is conditionalized at compile-time on ELF; unless I'm missing > something elfread.c is always built in regardless of the presence of ELF > targets. Should I not be using this function in this file? It doesn't really belong in symfile.c. It's certainly Linux-specific at the moment, so it belongs in a file specific to the Linux ABI, but not specific to any processor (since all the architectures are going to use the syscall ABI, not just i386, right?). The file linux-nat.c isn't right, since it works fine over the remote protocol. I think we need a new file, linux-tdep.c. Linux maintainers, what do you think? The change itself looks fine. Reviewing it suggested various cleanups to symfile.c (say, symbol_file_add_with_addrs_or_offsets should always expect an opened BFD, and not take a name), but those are all independent of what you're trying to accomplish here, and needn't hold it up.