From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29215 invoked by alias); 8 Nov 2003 07:21:41 -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 29208 invoked from network); 8 Nov 2003 07:21:40 -0000 Received: from unknown (HELO palrel11.hp.com) (156.153.255.246) by sources.redhat.com with SMTP; 8 Nov 2003 07:21:40 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by palrel11.hp.com (Postfix) with ESMTP id 5BC751C00C06; Fri, 7 Nov 2003 23:21:39 -0800 (PST) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by hplms2.hpl.hp.com (8.12.10/8.12.10/HPL-PA Hub) with ESMTP id hA87Lcs4007489; Fri, 7 Nov 2003 23:21:38 -0800 (PST) Received: from napali.hpl.hp.com (napali [127.0.0.1]) by napali.hpl.hp.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id hA87LcFO025257; Fri, 7 Nov 2003 23:21:38 -0800 Received: (from davidm@localhost) by napali.hpl.hp.com (8.12.3/8.12.3/Debian-6.6) id hA87Lc9t025253; Fri, 7 Nov 2003 23:21:38 -0800 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16300.39298.323956.667764@napali.hpl.hp.com> Date: Sat, 08 Nov 2003 07:21:00 -0000 To: Andrew Cagney Cc: Kevin Buettner , davidm@hpl.hp.com, "J. Johnston" , gdb-patches@sources.redhat.com Subject: Re: RFA: ia64 portion of libunwind patch In-Reply-To: <3FAC388A.10207@redhat.com> References: <3FA2B71A.3080905@redhat.com> <3FA2CA1B.7000502@redhat.com> <16290.59502.799536.383397@napali.hpl.hp.com> <3FAC12D3.2070207@redhat.com> <16300.8192.489647.740612@napali.hpl.hp.com> <3FAC2454.2030009@redhat.com> <16300.9949.513264.716812@napali.hpl.hp.com> <3FAC2D03.8070607@redhat.com> <16300.12503.585501.180768@napali.hpl.hp.com> <3FAC33B3.2030403@redhat.com> <1031108001337.ZM18506@localhost.localdomain> <3FAC388A.10207@redhat.com> Reply-To: davidm@hpl.hp.com X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ X-SW-Source: 2003-11/txt/msg00152.txt.bz2 >>>>> On Fri, 07 Nov 2003 19:27:54 -0500, Andrew Cagney said: >> Because it may not have the elf binary (at least not locally), >> and it >>> may not have debug info. People still expect GDB to do >>> something reasonable in those cases. >> I'm a little bit puzzled about why we wouldn't have the elf >> binary... >> But, assuming for the moment that we do, we'll definitely have >> the unwind info since it's mandated by the ABI. Andrew> "at least not locally". The unwind info can always be found Andrew> in the target's memory. Andrew> There are two choices here: - make the interface more remote Andrew> friendly - just ignore the issue until someone complains Can you make it so that the local ELF image is used _when_ it's available? I personally never used gdb without specifying an executable file (I'm not even sure how that works), so I guess I'm willing to wait until someone complains (note that it's not as easy as simply setting table_data to NULL, because there would be no way to calculate the address of the unwind-table entry, so I'm not sure what you want could be done without breaking the existing API). Andrew> Hmm, a good question to ask is "how cross debug friendly" is Andrew> libunwind.? If its anything like libthread-db then this Andrew> discussion is mute. I don't know what the issue with libthread-db is, but libunwind is designed to be cross-debug friendly. It's a feature that gets regularly tested, e.g., as part of libunwind built into HP's ia64 simulator (which runs fine on x86 linux, for example). In theory, libunwind also support multiple unwind targets in the same binary, but this hasn't been tested much so far (but I also have no reason to believe that it doesn't work). --david