augusto2112 wrote: > I guess one question that might be relevant - does Swift have something like > sizeof and what result does it give for these sort of types with bits to > spare?
You can't actually use that with these types as these are special compiler builtin types which aren't actually accessible in source code. > But like I said - it seems like structs with tail padding are similar to this > situation - we still describe the whole size of the struct, because that's > used for creating arrays of instances, ABI passing, etc. But the tail padding > can still be used, in certain circumstances, when laying out a derived class. > We encode this as the POD-ness of the type, and so if you wanted to create a > class that derived from one described in DWARF you could do so & would know > whether or not to put the derived class's members into the tail padding of > the base or not. I understand the rationale of basing this on precedent, but in this case in this case we should break from it for two reasons: - DW_AT_BIT_SIZE is already a standardized attribute in Dwarf that fits this use case. - Round up to the nearest byte would lose information, which can be kept with fairly minimal downsides in my opinion. https://github.com/llvm/llvm-project/pull/69741 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
