From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <binutils-return-70260-listarch-binutils=sources.redhat.com@sourceware.org>
Received: (qmail 23339 invoked by alias); 24 Feb 2011 13:50:39 -0000
Received: (qmail 23319 invoked by uid 22791); 24 Feb 2011 13:50:37 -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; Thu, 24 Feb 2011 13:50:33 +0000
Received: by qwd7 with SMTP id 7so568209qwd.0        for <binutils@sourceware.org>; Thu, 24 Feb 2011 05:50:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.6.76 with SMTP id 12mr711570qay.299.1298555431039; Thu, 24 Feb 2011 05:50:31 -0800 (PST)
Received: by 10.224.61.18 with HTTP; Thu, 24 Feb 2011 05:50:30 -0800 (PST)
In-Reply-To: <1561346207520594884@unknownmsgid>
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>	<1561346207520594884@unknownmsgid>
Date: Thu, 24 Feb 2011 13:50:00 -0000
Message-ID: <AANLkTinC+rpP_G8gFn=EGgDYgBtQkyLw14QvKmZrPRn+@mail.gmail.com>
Subject: Re: [RFC patch]: Adjust the use of 'long' type in dwarf2.h header
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>
Cc: Kai Tietz <ktietz70@googlemail.com>, Binutils <binutils@sourceware.org>
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: <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/msg00291.txt.bz2

On Thu, Feb 24, 2011 at 3:33 AM, Pierre Muller
<pierre.muller@ics-cnrs.unistra.fr> wrote:
>> #if __GNUC__ >=3D 2
>> /* Define BFD64 here, even if our default architecture is 32 bit ELF
>> =A0 =A0as this will allow us to read in and parse 64bit and 32bit ELF
>> files.
>> =A0 =A0Only do this if we believe that the compiler can support a 64 bit
>> =A0 =A0data type. =A0For now we only rely on GCC being able to do this. =
=A0*/
>> #define BFD64
>> #endif
>>
>> ....
>> #include "dwarf.h"
>> ---
>>
>> dwarf_vma should be the same inside and outside of readelf.c.
>
>
> =A0This 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.
>
> =A0dwarf.c still mainly uses bfd_vma
> and has dwarf_vma only for one function
> get_encoded_value...
>
> =A0Should read_leb128 (and maybe other functions within
> dwarf.c) also be changed to use
> dwarf_vma rather than bfd_vma in that case?
>

Probably since readelf.c has

static unsigned long
read_uleb128 (unsigned char *data, unsigned int *length_return)
{
  return read_leb128 (data, length_return, 0);
}



--=20
H.J.