4 Commits

Author SHA1 Message Date
Jonas Devlieghere
2238dcc393
[NFC][Py Reformat] Reformat python files in lldb
This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).

If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.

RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Differential revision: https://reviews.llvm.org/D151460
2023-05-25 12:54:09 -07:00
Dave Lee
4cc8f2a017 [lldb][tests] Automatically call compute_mydir (NFC)
Eliminate boilerplate of having each test manually assign to `mydir` by calling
`compute_mydir` in lldbtest.py.

Differential Revision: https://reviews.llvm.org/D128077
2022-06-17 14:34:49 -07:00
Raphael Isemann
2ce889fa4e [lldb][NFC] Add size tests for empty records with alignment and with empty members
This came up during the Windows bot failure discussing after D105471 . See
also 3d9a9fa6911a5228ce799a7c639e94d322678934 .
2021-08-30 16:38:13 +02:00
Raphael Isemann
67c588c481 [lldb] Generalize empty record size computation to avoid giving empty C++ structs a size of 0
C doesn't allow empty structs but Clang/GCC support them and give them a size of 0.

LLDB implements this by checking the tag kind and if it's `DW_TAG_structure_type` then
we give it a size of 0 via an empty external RecordLayout. This is done because our
internal TypeSystem is always in C++ mode (which means we would give them a size
of 1).

The current check for when we have this special case is currently too lax as types with
`DW_TAG_structure_type` can also occur in C++ with types defined using the `struct`
keyword. This means that in a C++ program with `struct Empty{};`, LLDB would return
`0` for `sizeof(Empty)` even though the correct size is 1.

This patch removes this special case and replaces it with a generic approach that just
assigns empty structs the byte_size as specified in DWARF. The GCC/Clang special
case is handles as they both emit an explicit `DW_AT_byte_size` of 0. And if another
compiler decides to use a different byte size for this case then this should also be
handled by the same code as long as that information is provided via `DW_AT_byte_size`.

Reviewed By: werat, shafik

Differential Revision: https://reviews.llvm.org/D105471
2021-07-22 13:30:48 +02:00