dwblaikie wrote: > @dwblaikie I talked with Adrian, his idea is to emit the size in bits > whenever it does not cleanly fit in a byte. His point (and I agree) is that > there may be tools that can use this bit size, and if we always round up when > emitting the DWARF we will lose this information, with no way to recover it. > I updated the patch to implement this behavior.
Yeah - ultimately it's pretty much up to you folks how you encode Swift and ObjC things - so take anything I'm saying as advice but not requirement. But it feels a bit at-odds with precedent in the way other things that seem similar to me are encoded in DWARF already, and precedent is pretty much most/all we have to go with in DWARF. 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? 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. 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
