From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5756 invoked by alias); 13 Feb 2012 19:20:25 -0000 Received: (qmail 5747 invoked by uid 22791); 13 Feb 2012 19:20:24 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Feb 2012 19:20:08 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1DJJk1J010463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Feb 2012 14:19:46 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q1DJJjQO025596; Mon, 13 Feb 2012 14:19:46 -0500 Message-ID: <4F396251.9020409@redhat.com> Date: Mon, 13 Feb 2012 19:20:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: Jan Kratochvil CC: Tristan Gingold , "gdb-patches@sourceware.org ml" Subject: Re: RFA: Try to include libunwind-ia64.h in libunwind-frame.h References: <5D1CD28F-F628-475C-B6D8-5FCBF5290C63@adacore.com> <20120210182705.GA32459@host2.jankratochvil.net> <4F3562FE.7050106@redhat.com> <20120211140919.GA24043@host2.jankratochvil.net> <4F395D17.5070303@redhat.com> <20120213190223.GA8851@host2.jankratochvil.net> In-Reply-To: <20120213190223.GA8851@host2.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-02/txt/msg00243.txt.bz2 On 02/13/2012 07:02 PM, Jan Kratochvil wrote: > On Mon, 13 Feb 2012 19:57:27 +0100, Pedro Alves wrote: >> I don't understand why we ever include "libunwind.h" though. > >> libunwind is only ever used by ia64 currently. > > It is required for ia64 but it can be used even with non-ia64 archs. How? AFAICS, no other target installs the libunwind sniffer. It's just dead code on other archs, if I'm reading the code correctly. > I do not have it tested, though. I will test it before a check-in. > > >> If some other target wanting to use libunwind shows up, then we'll need to >> include libunwind-fooarch.h instead > > For native configuration libunwind.h includes the right libunwind-fooarch.h > for us. > /usr/include/libunwind.h > #if defined __arm__ > # include "libunwind-arm.h" > #elif defined __hppa__ > # include "libunwind-hppa.h" > [...] > > The cross-build does not work for ia64 well this way, though. So libunwind > for non-ia64 works even in the non-cross mode. This is the part I did not > want to start implementing as it may get all more complex. Sure. We don't make sure to include (literaly) "libunwind.h" only when native, so it's conceptually wrong to include it in target dependent files. > >> IOW, "libunwind.h" will always be conceptually wrong for gdb. > > libunwind has pretty active development, I can imaging libunwind developers > / enthusiasts would like to use it for GDB on x86*. I did not say libunwind the library itself is conceptually wrong. :-) I'm talking about including the literal "libunwind.h" header. Including the literal "libunwind.h" file directly will always be conceptually wrong for gdb, because that includes the libunwind header for the host gdb is running on. The right conceptual model for gdb is to always treat libunwind as remote/cross, and thus always include the arch specific libunwind-foo.h header. -- Pedro Alves