[PATCH] D82881: [DEBUGINFO]Fix debug info for packed bitfields.

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D82881#2135641 <https://reviews.llvm.org/D82881#2135641>, @ABataev wrote:

> In D82881#2134913 <https://reviews.llvm.org/D82881#2134913>, @dblaikie wrote:
>
> > In D82881#2133548 <https://reviews.llvm.org/D82881#2133548>, @ABataev wrote:
> >
> > > In D82881#2133511 <https://reviews.llvm.org/D82881#2133511>, @aprantl wrote:
> > >
> > > > And conversely, with this patch applied, do GDB and LLDB still produce the expected result?
> > >
> > >
> > > GDB works correctly. Did not check with lldb, but it also should work. The result is similar to the debug info, produced for the next code:
> > >
> > >   struct {
> > >   short : 3;
> > >   short : 6;
> > >   } a;
> > >
> >
> >
> > Similar, but seems different in a critical way - in that code, the type of the field is short, which has size 2. Which matches the size of the field.
> >
> > I think it would be pretty surprising to handle DWARF where the size of a field is different from the size of the type of that field?
>
>
> The standard clearly says:
>  A base type entry has a DW_AT_byte_size attribute, whose value is a constant, describing the size in bytes of the storage unit used to represent an object of the given type.
>  In our example, the storage size is the same, just like for short.


The storage size is the same as what?

It looks like/my understanding is this patch produces a field of type 'char' with size 2 bytes - which seems surprisingly inconsistent, at least. If there are other pre-existing examples of fields having larger sizes than their types, that might be useful to draw analogy and confidence from.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82881/new/

https://reviews.llvm.org/D82881