From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18876 invoked by alias); 20 Feb 2012 22:01:35 -0000 Received: (qmail 18863 invoked by uid 22791); 20 Feb 2012 22:01:34 -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, 20 Feb 2012 22:01:11 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1KM0wIM028810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Feb 2012 17:00:58 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q1KM0ra8007671; Mon, 20 Feb 2012 17:00:56 -0500 Message-ID: <4F42C295.6010905@redhat.com> Date: Mon, 20 Feb 2012 22:30: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: Pedro Alves , Tristan Gingold , "gdb-patches@sourceware.org ml" Subject: Re: RFA: Try to include libunwind-ia64.h in libunwind-frame.h References: <20120211140919.GA24043@host2.jankratochvil.net> <4F395D17.5070303@redhat.com> <20120213190223.GA8851@host2.jankratochvil.net> <4F396251.9020409@redhat.com> <20120213192652.GA11522@host2.jankratochvil.net> <4F396CDC.7020504@redhat.com> <20120214072735.GA21362@host2.jankratochvil.net> <4F3A5001.4090500@redhat.com> <20120214143545.GA22678@host2.jankratochvil.net> <4F3A7531.6050303@redhat.com> <20120220204351.GA15256@host2.jankratochvil.net> In-Reply-To: <20120220204351.GA15256@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/msg00420.txt.bz2 On 02/20/2012 08:43 PM, Jan Kratochvil wrote: > On Tue, 14 Feb 2012 15:52:33 +0100, Pedro Alves wrote: >> I don't understand what are we discussing. The possibility is there, but it >> needs work to get there. When the future comes, we'll have to adjust. Right >> now, nobody but IA-64 cares. Making the limitation explicit by including >> the ia64 header directly doesn't make the needed work more difficult one >> single bit. On the contrary. > > I do not understand what is the goal here now. Fix GDB's broken inclusion of "libunwind.h". As I've explained before, including "libunwind.h" in GDB is _always_ wrong for GDB. Including the libunwind-$arch.h file directly is the right thing to do. That's what needs fixing. I haven't seen any counter argument to that. > Therefore either > > (a) Let's finish multi-arch support for libunwind. I don't imagine how any multi-arch work we do to libunwind would make it possible to include "libunwind.h". But if there's a clean way to make that work, I'd like to know about it. But in any case, this is much more than the real need we have now. And I don't see why we can't fix the include problem, and do multi-arching as follow up work as necessary. > > or > > (b) Let's make libunwind support ia64-exclusive. It already is implicitly. No other arch uses it. If any other arch wants to use the file, then you would have two archs in the same GDB build wanting to use the code, so then it'd be _really_ obvious that including "libunwind.h" doesn't work. How would an --enable-targets=all build work? I've added comments to the files to make that explicitly clear. Why invent more work? (c) Fix the real problem with the code, which is that it includes "libunwind.h", when that is the wrong thing to do for GDB. > The state is in between I have no clue what is a valid patch anymore. > I am for (b). I don't see how different the result will be from today's state, so I don't see the big benefit... That'd take us further from being able to use the code on other archs, but if you want to do it, fine with me. Any other opinions before I (or anyone else) write a patch? -- Pedro Alves