From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29269 invoked by alias); 23 Feb 2011 17:42:26 -0000 Received: (qmail 29259 invoked by uid 22791); 23 Feb 2011 17:42:25 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-qy0-f169.google.com (HELO mail-qy0-f169.google.com) (209.85.216.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Feb 2011 17:42:19 +0000 Received: by qyk2 with SMTP id 2so4055002qyk.0 for ; Wed, 23 Feb 2011 09:42:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.212.5 with SMTP id gq5mr3365424qcb.64.1298482937796; Wed, 23 Feb 2011 09:42:17 -0800 (PST) Received: by 10.229.89.197 with HTTP; Wed, 23 Feb 2011 09:42:17 -0800 (PST) In-Reply-To: <-2339605939192327273@unknownmsgid> References: <-8460070221060995487@unknownmsgid> <-6930711422310680743@unknownmsgid> <4D63D49D.90101@redhat.com> <-2339605939192327273@unknownmsgid> Date: Wed, 23 Feb 2011 17:42:00 -0000 Message-ID: Subject: Re: [RFC patch]: Adjust the use of 'long' type in dwarf2.h header From: Kai Tietz To: Pierre Muller Cc: 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/msg00283.txt.bz2 2011/2/23 Pierre Muller : > =A0Kai, > > 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_signed_vma' > type that must be signed 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. > > > Pierre Muller > GDB pascal language maintainer > > > >> -----Message d'origine----- >> De=A0: binutils-owner@sourceware.org [mailto:binutils- >> owner@sourceware.org] De la part de Kai Tietz >> Envoy=E9=A0: mercredi 23 f=E9vrier 2011 10:00 >> =C0=A0: Nick Clifton >> Cc=A0: Pierre Muller; GCC Patches; Binutils; gdb; Jakub Jelinek; Joel >> Brobecker >> Objet=A0: Re: [RFC patch]: Adjust the use of 'long' type in dwarf2.h >> header >> >> 2011/2/22 Nick Clifton : >> > Hi Kai, >> > >> > >> >> So this version uses new function dwarf_vma_print function for >> >> printf-messages, which are getting localized. >> >> >> >> Tested for x86_64-w64-mingw32 and x86_64-pc-linux-gnu. Ok for apply? >> > >> >> +static const char * >> >> +dwarf_vma_print (const char *fmtch, bfd_vma value) >> > >> > I think that I prefer your suggestion of dwarf_vmatoa. >> > >> >> +{ >> >> + =A0static int buf_pos =3D 0; >> >> + =A0static struct dwarf_vma_print_buf { >> >> + =A0 =A0char place[64]; >> >> + =A0} buf[16]; >> > >> > Ideally you should have a comment here explaining why you have an >> array of >> > these string buffers. >> > >> >> + =A0char fmt[32]; >> >> + =A0char *ret; >> >> + >> >> + =A0sprintf (fmt, "%%%s%s", BFD_VMA_FMT, fmtch); >> >> + =A0ret =3D &buf[buf_pos++].place[0]; >> > >> > Or, more simply: >> > >> > =A0ret =3D buf[buf_pos++].place; >> > >> >> + =A0buf_pos &=3D 15; >> > >> > That "15" should be: "ARRAY_SIZE (buf) - 1", and it would be safer to >> write: >> > >> > =A0buf_pos %=3D ARRAY_SIZE (buf); >> > >> > and leave it to the compiler to optimize this into an AND operation >> if it >> > can. >> > >> >> snprintf (ret, 64, fmt, value); >> > >> > And the "64" here should be "sizeof (buf[0].place)". >> > >> > Cheers >> > =A0Nick >> > >> > >> >> Hello Nick, >> >> adjust the binutils part as you suggested. Applied to binutils and gcc >> (rev. 170433) tree. >> >> Regards, >> Kai 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. So what exactly is the point where you see here still the use of dw2_vma_t/dw2_svma_t? Regards, Kai