This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [lto] PATCH: preserve precision of odd-sized integral types

Daniel Jacobowitz wrote:
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?

Yes, I thought at first that I might have to conditionalize this code depending on endianness, but I came to exactly the same conclusion -- the value is always stored in the low-order bits no matter which way they're numbered.

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.

I was kind of afraid of that, but I suspect GDB will never see values of "weird"-sized types produced by the existing front ends, anyway. E.g., bit_size_type is used internally in the tree structure for the types of constants that represent object sizes in bits, but it doesn't correspond to any C integral type.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]