From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32585 invoked by alias); 23 Apr 2004 04:35:06 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 32572 invoked from network); 23 Apr 2004 04:35:01 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 23 Apr 2004 04:35:01 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3N4Z0KG014811 for ; Fri, 23 Apr 2004 00:35:00 -0400 Received: from zenia.home.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3N4Ywp30503; Fri, 23 Apr 2004 00:34:59 -0400 To: Roland McGrath Cc: Randolph Chung , gdb@sources.redhat.com Subject: Re: add-symbol-file-from-memory patch breaks non-elf targets? References: <200404230418.i3N4Iuu3005779@magilla.sf.frob.com> From: Jim Blandy Date: Fri, 23 Apr 2004 10:05:00 -0000 In-Reply-To: <200404230418.i3N4Iuu3005779@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: 2004-04/txt/msg00142.txt.bz2 Roland McGrath writes: > It's unfortunate that this is done in a way that requires a tweak for every > specific target. The functionality will work, and thus ought to be > available, on any ELF target. The use of symbol_file_add_from_memory from > other gdb code to support Linux's vDSO is already needed on more than one > Linux target and it is not unlikely that other Linux targets will follow > suit in the future. It is crufty and makes maintenance error prone if we > have nothing better than copying and updating makefile boilerplate for > every specific Linux/CPU target. For example, your patch covers only x86 > and powerpc, but already IA64 and x86-64 need this support (and AFAIK not > yet powerpc). But "any ELF target" is not a well-defined thing in GDB. GDB just tries to cope with whatever it gets. GDB lets BFD keep track of what object file formats are appropriate for what targets. The reason I thought this approach would be appropriate is that it resembles the way we handle the different dynamic linker debugging protocols: each .mt file selects solib-mumble.o manually. As far as I know, this hasn't been much of a maintenance hassle.