This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: incorrect signed data
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Fri, 07 Feb 2014 22:19:35 +0100
- Subject: Re: incorrect signed data
On Thu, 2014-02-06 at 13:56 +0100, Mark Wielaard wrote:
> On Wed, 2014-02-05 at 14:59 -0800, Josh Stone wrote:
> > Here's gdb precedent for the status quo, not sign-extending, in the
> > comment right before dwarf2_const_value_data in gdb/dwarf2read.c:
> >
> > /* Given an attr with a DW_FORM_dataN value in host byte order,
> > zero-extend it as appropriate for the symbol's type. The DWARF
> > standard (v4) is not entirely clear about the meaning of using
> > DW_FORM_dataN for a constant with a signed type, where the type is
> > wider than the data. The conclusion of a discussion on the DWARF
> > list was that this is unspecified. We choose to always zero-extend
> > because that is the interpretation long in use by GCC. */
>
> I also found the following comment in the GCC sources:
>
> /* ??? It would be slightly more efficient to use a scheme like is
> used for unsigned constants below, but gdb 4.x does not sign
> extend. Gdb 5.x does sign extend. */
>
> That is just before trying to output a possible signed constant value.
> It will always use DW_FORM_sdata as sleb128 for that.
>
> The GCC comment is incomplete because you showed that recent GDBs (at
> least since 2010) reverted to the 4.x behavior again.
And I now found the discussion on the gdb patches list:
https://sourceware.org/ml/gdb-patches/2010-07/msg00437.html
Which funnily brings it back to us again:
"Both GCC and elfutils agreed that DW_FORM_data* are "just bits" -- no
sign extension is to be applied."
Grin,
Mark