[Lldb-commits] [lldb] [llvm] Emit DIE's size in bits when size is not a multiple of 8 (PR #69741)
dwblaikie wrote: > > I'm arguing it doesn't fit it particularly well. We use it for bit fields - > > which are pretty special, for instance, but it seems like this thing isn't > > quite like that - it does have a whole byte size (if you allocated an array > > of them, for instance, I'm guessing they're a byte each, right?) but then > > has some padding bits that can be reused in some circumstances? That's why > > I'm saying it seems like it fits more closely to the struct padding > > representation. > > Swift is really clever at packing at packing aggregate types. For example, > the discriminator bits for enums are always stored in unused bits of the > payload type. For a contrived example, the type Optional has a size > of 3 bits. Sure enough - C++ tail padding does similar things: https://godbolt.org/z/4jsYWK6ev - where t2's member is packed into the tail padding of t1, but still leaves more tail padding for t3. (it's not identical, of course - it's somewhere between C++ tail padding and the ad-hoc stuff we have in LLVM for PointerIntPair, where multiple of those can be nested together and use the remaining bits for another element) 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
[Lldb-commits] [lldb] [llvm] Emit DIE's size in bits when size is not a multiple of 8 (PR #69741)
adrian-prantl wrote: > I'm arguing it doesn't fit it particularly well. We use it for bit fields - > which are pretty special, for instance, but it seems like this thing isn't > quite like that - it does have a whole byte size (if you allocated an array > of them, for instance, I'm guessing they're a byte each, right?) but then has > some padding bits that can be reused in some circumstances? That's why I'm > saying it seems like it fits more closely to the struct padding > representation. Swift is really clever at packing at packing aggregate types. For example, the discriminator bits for enums are always stored in unused bits of the payload type. For a contrived example, the type Optional> has a size of 3 bits. 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
[Lldb-commits] [lldb] [llvm] Emit DIE's size in bits when size is not a multiple of 8 (PR #69741)
dwblaikie 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. Perhaps observable indirectly? > > 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. I'm arguing it doesn't fit it particularly well. We use it for bit fields - which are pretty special, for instance, but it seems like this thing isn't quite like that - it does have a whole byte size (if you allocated an array of them, for instance, I'm guessing they're a byte each, right?) but then has some padding bits that can be reused in some circumstances? That's why I'm saying it seems like it fits more closely to the struct padding representation. > * Round up to the nearest byte would lose information, which can be kept with > fairly minimal downsides in my opinion. Seems like it'd still need to be special cased, right? The consumer would go "oh, this has a bit size, but if we want an array of them, or to allocate them for ABI purposes, etc, I have to round it up to the nearest byte"? or something like that. Some pointers to documentation about these types, and the range of uses/instances there are might be handy (like is this a general concept? Or is it only one type that uses this (`bool` equivalent, with 7 padding bytes unused) or a class of types (a small finite list of them? Unbounded (like if I put a bool in my custom struct - does my custom struct end up with a bit size too?)) 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
[Lldb-commits] [lldb] [llvm] Emit DIE's size in bits when size is not a multiple of 8 (PR #69741)
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
[Lldb-commits] [lldb] [llvm] Emit DIE's size in bits when size is not a multiple of 8 (PR #69741)
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
[Lldb-commits] [lldb] [llvm] Emit DIE's size in bits when size is not a multiple of 8 (PR #69741)
@@ -2866,8 +2879,12 @@ void DWARFASTParserClang::ParseSingleMember( // Get the parent byte size so we can verify any members will fit const uint64_t parent_byte_size = parent_die.GetAttributeValueAsUnsigned(DW_AT_byte_size, UINT64_MAX); - const uint64_t parent_bit_size = - parent_byte_size == UINT64_MAX ? UINT64_MAX : parent_byte_size * 8; + uint64_t parent_bit_size; + if (parent_byte_size != UINT64_MAX) +parent_bit_size = parent_byte_size * 8; + else +parent_bit_size = +parent_die.GetAttributeValueAsUnsigned(DW_AT_bit_size, UINT64_MAX); Michael137 wrote: DWARFASTParserClang has unittests where we sometimes use Yaml2Obj and directly invoke the parser. But it's quite finicky. Let me know if you run into troubles with it 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
