From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <binutils-return-70259-listarch-binutils=sources.redhat.com@sourceware.org>
Received: (qmail 29528 invoked by alias); 24 Feb 2011 11:33:23 -0000
Received: (qmail 29519 invoked by uid 22791); 24 Feb 2011 11:33:23 -0000
X-SWARE-Spam-Status: No, hits=-1.3 required=5.0	tests=AWL,BAYES_00,MSGID_MULTIPLE_AT
X-Spam-Check-By: sourceware.org
Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.152)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Feb 2011 11:33:17 +0000
Received: from md1.u-strasbg.fr (md1.u-strasbg.fr [IPv6:2001:660:2402::186])           by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id p1OBXB1d002714           ; Thu, 24 Feb 2011 12:33:12 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr)
Received: from mailserver.u-strasbg.fr (ms1.u-strasbg.fr [130.79.204.10])           by md1.u-strasbg.fr (8.14.4/jtpda-5.5pre1) with ESMTP id p1OBXBO8040959           ; Thu, 24 Feb 2011 12:33:11 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr)
Received: from E6510Muller (gw-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN)          by mailserver.u-strasbg.fr (8.14.4/jtpda-5.5pre1) with ESMTP id p1OBXBVq079423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)          ; Thu, 24 Feb 2011 12:33:11 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr)
From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
To: "'H.J. Lu'" <hjl.tools@gmail.com>
Cc: "'Kai Tietz'" <ktietz70@googlemail.com>,        "'Binutils'" <binutils@sourceware.org>
References: <AANLkTimPMPKd=Hfz-1e_aSw_iQsdm2SMK5hwR0sd+tga@mail.gmail.com>	<-8460070221060995487@unknownmsgid>	<AANLkTingRFjfLtvFFVpJXuu1L_bV-0whUZOsL8z+s2L6@mail.gmail.com>	<-6930711422310680743@unknownmsgid>	<AANLkTimW3VCc977dAmo47m=k3KoNThFKcno1ALsQg=66@mail.gmail.com>	<AANLkTimHC_cR=Zb4JHBhBWcjn0Ypya1uzsjzZZRehSk=@mail.gmail.com>	<4D63D49D.90101@redhat.com>	<AANLkTi=v4XEzssnXK8z91n80jMe9bhtZh+2PtXY+_4vR@mail.gmail.com>	<-2339605939192327273@unknownmsgid>	<AANLkTi=SOpyBkHYFQRdsytdPb7b_DZ6Cf01DoZw4tLw+@mail.gmail.com>	<-3886800211494155692@unknownmsgid> <AANLkTimZ59JPpUSmqEaGGdT6c=pb+5mLQ1giCz8o=JB0@mail.gmail.com>
In-Reply-To: <AANLkTimZ59JPpUSmqEaGGdT6c=pb+5mLQ1giCz8o=JB0@mail.gmail.com>
Subject: RE: [RFC patch]: Adjust the use of 'long' type in dwarf2.h header
Date: Thu, 24 Feb 2011 11:33:00 -0000
Message-ID: <00ae01cbd416$9cefa070$d6cee150$@muller@ics-cnrs.unistra.fr>
MIME-Version: 1.0
Content-Type: text/plain;	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Mailing-List: contact binutils-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <binutils.sourceware.org>
List-Subscribe: <mailto:binutils-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/binutils/>
List-Post: <mailto:binutils@sourceware.org>
List-Help: <mailto:binutils-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: binutils-owner@sourceware.org
X-SW-Source: 2011-02/txt/msg00290.txt.bz2

> #if __GNUC__ >= 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.


  This means, if I understand this correctly that
if I compile a 32 bit readelf executable
bfd_vma will be a 64-bit integer inside readelf.c,
but a 32-bit integer in dwarf.c.

  dwarf.c still mainly uses bfd_vma
and has dwarf_vma only for one function
get_encoded_value...

  Should read_leb128 (and maybe other functions within
dwarf.c) also be changed to use
dwarf_vma rather than bfd_vma in that case?

Pierre