Skip to content

Conversation

@Michael137
Copy link

This patch ensures we make use of the DW_AT_bit_size on
DW_TAG_base_types and adjusts TypeSystemClang to recognize _BitInt.

For DWARF from older versions of Clang that didn't emit a
DW_AT_bit_size, we would create _BitInts using the byte-size. Not
sure we can do much better than that. But the situation beforehand
wasn't much better.

Before:

(lldb) v
(char) a = '\x01'
(unsigned char) b = '\x01'
(long) c = 2
(unsigned long) d = 2

After:

(lldb) v
(_BitInt(2)) a = 1
(unsigned _BitInt(2)) b = 1
(_BitInt(52)) c = 2
(unsigned _BitInt(52)) d = 2

(cherry picked from commit deb54ba)

@Michael137
Copy link
Author

@swift-ci test

1 similar comment
@Michael137
Copy link
Author

@swift-ci test

@Michael137 Michael137 force-pushed the bitint-debug-info-to-21.x branch from 8e16b6f to d27718a Compare November 5, 2025 08:10
@Michael137
Copy link
Author

@swift-ci test
@swift-ci test llvm

@Michael137
Copy link
Author

@swift-ci test

@Michael137 Michael137 force-pushed the bitint-debug-info-to-21.x branch from d27718a to 8e16b6f Compare November 5, 2025 09:10
Michael137 and others added 6 commits November 5, 2025 09:11
llvm#165702)

There were a couple of quirks with this parameter:
1. It wasn't being set consistently. E.g., vector types would be of
count `1` but complex types would be `2`. Hence, it wasn't clear what
count was referring to.
2. `count` was not being set if the input type was invalid, possibly
leaving the input reference uninitialized.
3. Only one callsite actually made use of `count`, and that in itself
seems like it could be improved (added a FIXME).

If we ever need a "how many elements does this type represent", we can
implement one with a new `TypeSystem` API that does exactly that.

(cherry picked from commit a6eac9e)
…Int types (llvm#164372)

DW_TAG_base_type DIEs are permitted to have both byte_size and bit_size
attributes "If the value of an object of the given type does not fully
occupy the storage described by a byte size attribute"

* Add DataSizeInBits to DIBasicType (`DIBasicType(... dataSize: n ...)` in IR).
* Change Clang to add DataSizeInBits to _BitInt type metadata.
* Change LLVM to add DW_AT_bit_size to base_type DIEs that have non-zero
  DataSizeInBits.

TODO: Do we need to emit DW_AT_data_bit_offset for big endian targets?
See discussion on the PR.

Fixes [llvm#61952](llvm#61952)

---------

Co-authored-by: David Stenberg <[email protected]>
(cherry picked from commit aa5fe56)
Follow on from llvm#164372

This changes the DW_AT_name for `_BitInt(N)` from `_BitInt` to `_BitInt(N)`

(cherry picked from commit 30579c0)
One (DWARF-spec compliant) exmample is:
llvm#164372, where we attach a
`DW_AT_bit_size` to `_BitInt` types that can't be exactly described by a
byte-size.

This patch adds support for `DW_AT_bit_size` to `DWARFASTParserClang`
when parsing type tags.

Note, we don't use this bit-size yet, but will do so in follow-up
patches.

(cherry picked from commit 9ed8896)
Depends on:
* llvm#165686

This patch ensures we make use of the `DW_AT_bit_size` on
`DW_TAG_base_type`s (which since
llvm#164372 can exist on
`_BitInt`s) and adjusts `TypeSystemClang` to recognize `_BitInt`.

For DWARF from older versions of Clang that didn't emit a
`DW_AT_bit_size`, we would create `_BitInt`s using the byte-size. Not
sure we can do much better than that. But the situation beforehand
wasn't much better.

Before:
```
(lldb) v
(char) a = '\x01'
(unsigned char) b = '\x01'
(long) c = 2
(unsigned long) d = 2
```

After:
```
(lldb) v
(_BitInt(2)) a = 1
(unsigned _BitInt(2)) b = 1
(_BitInt(52)) c = 2
(unsigned _BitInt(52)) d = 2
```

Fixes llvm#110273

(cherry picked from commit deb54ba)
@Michael137 Michael137 force-pushed the bitint-debug-info-to-21.x branch from 8e16b6f to 2823e28 Compare November 5, 2025 09:11
@Michael137
Copy link
Author

@swift-ci test

@Michael137
Copy link
Author

@swift-ci test llvm

@Michael137 Michael137 merged commit ebd0b1f into stable/21.x Nov 5, 2025
5 checks passed
@Michael137 Michael137 deleted the bitint-debug-info-to-21.x branch November 5, 2025 19:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants