From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22418 invoked by alias); 7 May 2004 20:38:04 -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 22401 invoked from network); 7 May 2004 20:38:04 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 7 May 2004 20:38:04 -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 i47Jq60o028806 for ; Fri, 7 May 2004 15:52:08 -0400 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i47Jq5v32363; Fri, 7 May 2004 15:52:05 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DE7D92B9D; Fri, 7 May 2004 15:52:05 -0400 (EDT) Message-ID: <409BE8E5.90007@gnu.org> Date: Fri, 07 May 2004 20:38:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Jim Blandy Cc: Roland McGrath , 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> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-05/txt/msg00058.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. No, that's also a bug. As part of multi-arch, GDB should be able to include multiple shlib mechanisms. Anyway, looks like I'm fixing this. Andrew