This is the mail archive of the
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: Thu, 06 Feb 2014 13:56:00 +0100
- Subject: Re: incorrect signed data
On Wed, 2014-02-05 at 14:59 -0800, Josh Stone wrote:
> On 02/05/2014 09:36 AM, Josh Stone wrote:
> > On 02/05/2014 03:44 AM, Mark Wielaard wrote:
> >> On Tue, 2014-02-04 at 18:24 -0800, Josh Stone wrote:
> >>> So now I'm not sure anything needs to change. At least dwarf_formsdata
> >>> should stay as-is for gcc.
> >> Are you sure? I think your original analysis is correct that
> >> dwarf_formsdata () is wrong and really should sign-extend.
> > No, see above; GCC wrote signed index 199 into a data1:199, so it would
> > be wrong to sign-extend this. We're at the mercy of the producer.
> 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.
Given that I agree that the current implementation of dwarf_formsdata
for DW_FORM_data to not sign-extend is correct (or at least
It does seem that only for DW_AT_[lower|upper]_bound the encoding with
data8 for negative values is used (luckily also on 32bit does it seem to
use data8). But in all other cases an actual negative constant value is
using DW_FORM_sdata. I don't fully understand why the bound attributes