From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27678 invoked by alias); 14 Feb 2012 14:53:12 -0000 Received: (qmail 27668 invoked by uid 22791); 14 Feb 2012 14:53:11 -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; Tue, 14 Feb 2012 14:52:56 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1EEqZ61013784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Feb 2012 09:52:35 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1EEqXwW022571; Tue, 14 Feb 2012 09:52:34 -0500 Message-ID: <4F3A7531.6050303@redhat.com> Date: Tue, 14 Feb 2012 14:53: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: <20120210182705.GA32459@host2.jankratochvil.net> <4F3562FE.7050106@redhat.com> <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> In-Reply-To: <20120214143545.GA22678@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/msg00268.txt.bz2 On 02/14/2012 02:35 PM, Jan Kratochvil wrote: > At least `libunwind_frame_unwind' is dead - it has no references in the > codebase - which confused me. It's dead for IA-64 as well. It's likely dead for any other arch that may want to use libunwind. So "if the non-ia64 libunwind support is therefore really removed the dead code in libunwind-frame.c should be also removed" is not the right justification to remove the dead code. If you want to remove it, go ahead, but do it because it's dead, period. > Also when you change GDB design by this patch - from arch-independent > libunwind-frame.c to ia64-limited libunwind-frame.c - one should best rename > libunwind-frame.[ch] to libunwind-ia64-frame.[ch]. Otherwise at least write > some comments there this file is used only for ia64 targets now. I have already added such comments to libunwind-frame.h. The limitation that the file is only usable by ia-64 is pre-existing. I'm not adding anything new, other than making the limitation _explicit_, which is a good thing. I'm adding this comment to libunwind-frame.c /* IA-64 is the only target that currently uses libunwind-frame. Note how UNW_TARGET, UNW_OBJ, etc. are compile time constants below. Those come from libunwind's headers, and are target dependent. Also, some of libunwind's typedefs are target dependent, as e.g., unw_word_t. If some other target wants to use this, we will need to do some abstracting in order to make it possible to select which libunwind we're talking to at runtime (and have one per arch). */ Are you fine with that? >> > The code is not really ia64 specific. > Yes, because it was designed to be possibly used in the future with arbirary > arch. 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. -- Pedro Alves