This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
[RFA] Supplemtal patch for use only dwarf_vma types in dwarf code
- From: "Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>
- To: "'Nick Clifton'" <nickc at redhat dot com>
- Cc: "'Kai Tietz'" <ktietz70 at googlemail dot com>, "'H.J. Lu'" <hjl dot tools at gmail dot com>, "'Binutils'" <binutils at sourceware dot org>
- Date: Fri, 25 Mar 2011 16:48:11 +0100
- Subject: [RFA] Supplemtal patch for use only dwarf_vma types in dwarf code
- 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> <AANLkTinC+rpP_G8gFn=EGgDYgBtQkyLw14QvKmZrPRn+@mail.gmail.com> <5095785081977025060@unknownmsgid> <AANLkTik9=KVF+gX9yR-=EtnHDnnOmWG2wGaKqbDXn9Os@mail.gmail.com> <00d601cbd4f0$c911af10$5b350d30$@muller@ics-cnrs.unistra.fr> <4D8CB1F5.6020108@redhat.com>
> -----Message d'origine-----
> De?: binutils-owner@sourceware.org [mailto:binutils-owner@sourceware.org]
De
> la part de Nick Clifton
> Envoyé?: vendredi 25 mars 2011 16:17
> À?: Pierre Muller
> Cc?: 'Kai Tietz'; 'H.J. Lu'; 'Binutils'
> Objet?: Re: [RFC-v2] Use only dwarf_vma types in dwarf code
>
> Hi Pierre,
>
> [only a month late...]
> Approved and applied - along with a little tidying up.
Thanks,
I have a few remaining changes to propose:
always in the spirit of the previous RFC,
use dwarf_vma whenever we are not sure that a 'long'
(which can be shorter than a pointer in byte size
on mingw64 system) is enough.
I have no real idea if those three cases are
really variables that can reach up to values that
do not fit in 4-bytes but it can not really hurt, can it?
Pierre Muller
ChangeLog entry:
2011-03-25 Pierre Muller <muller@ics.u-strasbg.fr>
* dwarf.c (decode_location_expression): Use dwarf_vmatoa
function to display DW_OP_addr OP.
(process_debug_info): Use dwarf_vma type for local variables
length and type_offset.
Index: dwarf.c
===================================================================
RCS file: /cvs/src/src/binutils/dwarf.c,v
retrieving revision 1.86
diff -u -p -r1.86 dwarf.c
--- dwarf.c 25 Mar 2011 15:15:52 -0000 1.86
+++ dwarf.c 25 Mar 2011 15:39:49 -0000
@@ -674,8 +674,8 @@ decode_location_expression (unsigned cha
switch (op)
{
case DW_OP_addr:
- printf ("DW_OP_addr: %lx",
- (unsigned long) byte_get (data, pointer_size));
+ printf ("DW_OP_addr: %s",
+ dwarf_vmatoa("x", byte_get (data, pointer_size)));
data += pointer_size;
break;
case DW_OP_deref:
@@ -1926,7 +1926,7 @@ process_debug_info (struct dwarf_section
&& num_debug_info_entries == 0
&& ! do_types)
{
- unsigned long length;
+ dwarf_vma length;
/* First scan the section to get the number of comp units. */
for (section_begin = start, num_units = 0; section_begin < end;
@@ -2002,7 +2002,7 @@ process_debug_info (struct dwarf_section
int offset_size;
int initial_length_size;
unsigned char signature[8] = { 0 };
- unsigned long type_offset = 0;
+ dwarf_vma type_offset = 0;
hdrptr = start;
@@ -2084,7 +2084,8 @@ process_debug_info (struct dwarf_section
for (i = 0; i < 8; i++)
printf ("%02x", signature[i]);
printf ("\n");
- printf (_(" Type Offset: 0x%lx\n"), type_offset);
+ printf (_(" Type Offset: 0x%s\n"),
+ dwarf_vmatoa ("x", type_offset));
}
}