This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [lto] PATCH: preserve precision of odd-sized integral types
- From: Daniel Jacobowitz <dan at codesourcery dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Sandra Loosemore <sandra at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Kenneth Zadeck <zadeck at naturalbridge dot com>
- Date: Tue, 10 Oct 2006 12:30:45 -0400
- Subject: Re: [lto] PATCH: preserve precision of odd-sized integral types
- References: <452BA720.9060706@codesourcery.com> <452BC884.80802@codesourcery.com>
On Tue, Oct 10, 2006 at 09:21:24AM -0700, Mark Mitchell wrote:
> >+ if (TREE_CODE (type) == INTEGER_TYPE
> >+ && TYPE_PRECISION (type) < byte_size * BITS_PER_UNIT)
> >+ {
> >+ add_AT_unsigned (base_type_result, DW_AT_bit_size,
> >+ TYPE_PRECISION (type));
> >+ add_AT_unsigned (base_type_result, DW_AT_bit_offset,
> >+ byte_size * BITS_PER_UNIT - TYPE_PRECISION (type));
> >+ }
>
> Does DW_AT_bit_offset probably depend on the {bit,byte}-endianness of
> the target? The DWARF spec says:
>
> "The bit offset attribute describes the offset in bits of the high order
> bit of a value of the given type from the high order bit of the storage
> unit used to contain that value."
>
> So, for a big-endian system, I'd sort-of expect the value to be zero.
> Daniel, can you help here? I see that in the reader, you check that
> that the values are as you expect in this respect, but I'm not sure that
> the data you're emitting is correct for big-endian systems.
Thinking about it a little, I think Sandra's right. Won't we store a
30-bit value in the low 30 bits of a 32-bit word, regardless of
endianness?
GDB won't get this sort of thing right anyway. If you want to use it
to poke at the new and improved debug info, it'll need some new and
improving of its own.
--
Daniel Jacobowitz
CodeSourcery