From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17343 invoked by alias); 23 Feb 2011 22:51:46 -0000 Received: (qmail 17332 invoked by uid 22791); 23 Feb 2011 22:51:45 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-qw0-f41.google.com (HELO mail-qw0-f41.google.com) (209.85.216.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Feb 2011 22:51:40 +0000 Received: by qwd7 with SMTP id 7so4327083qwd.0 for ; Wed, 23 Feb 2011 14:51:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.204.137 with SMTP id fm9mr52215qab.199.1298501498967; Wed, 23 Feb 2011 14:51:38 -0800 (PST) Received: by 10.224.61.18 with HTTP; Wed, 23 Feb 2011 14:51:38 -0800 (PST) In-Reply-To: <-3886800211494155692@unknownmsgid> References: <-8460070221060995487@unknownmsgid> <-6930711422310680743@unknownmsgid> <4D63D49D.90101@redhat.com> <-2339605939192327273@unknownmsgid> <-3886800211494155692@unknownmsgid> Date: Wed, 23 Feb 2011 22:51:00 -0000 Message-ID: Subject: Re: [RFC patch]: Adjust the use of 'long' type in dwarf2.h header From: "H.J. Lu" To: Pierre Muller Cc: Kai Tietz , Binutils Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00287.txt.bz2 On Wed, Feb 23, 2011 at 1:55 PM, Pierre Muller wrote: >> Applied patch don't have those types any more. I introduced them in >> initial patch under assumption structures in include/dwarf2.h should >> be host-independent. As now those structures are moved into binutils >> private header binutils/dwarf.h there is no need to have here new >> types and patch uses bfd_vma/bfd_signed_vma. > > =A0Whoops, my fault, indeed! > >> So what exactly is the point where you see here still the use of >> dw2_vma_t/dw2_svma_t? > > =A0Oh, sorry, you are right, > I didn't realize that the new > introduced type called 'dwarf_vma' > was in fact introduced back to 2010 ... > by a commit by H.J. Lu from 2010-11-21. > > =A0So that my question in fact should have been sent to > H.J. Lu, not to you. > > So let me re-ask the question to the right person: > > > please excuse me for asking this so late, > but I don't really understand why you had to introduce > a new 'dwarf_vma' type when we already have a 'bfd_vma' > type that must be unsigned 64-bit as soon as > BFD64 macro is defined... > See definitions in bfd/bfd-in.h or bfd/bfd-in2.h > > This macro should be set if any of the supported target is a 64-bit target > so it should be possible to use that type, no? > > =A0But of course, I might be missing some important point, > could you please explain to me in which case > a 64-bit dwarf_vma could be necessary without BFD64 being set. > (I just realized in between that dwarf_vma is an unsigned type.) > > =A0I still think that my question is valid, > but I was unable to find the discussion about the > patch in the mailing list which might contain > an explanation. > > =A0H.J., could you please give me a pointer > to the thread where the patch is explained or > comment on my question? dwarf.h is also used by readelf.c, whose feature isn't controlled by BFD64: --- #if __GNUC__ >=3D 2 /* Define BFD64 here, even if our default architecture is 32 bit ELF as this will allow us to read in and parse 64bit and 32bit ELF files. Only do this if we believe that the compiler can support a 64 bit data type. For now we only rely on GCC being able to do this. */ #define BFD64 #endif .... #include "dwarf.h" --- dwarf_vma should be the same inside and outside of readelf.c. --=20 H.J.