labath added a comment.
The fact that MSVC does not store all of the anonymous union data is
unfortunate, though not entirely surprising, given that the goal of debug info
never was to offer an exact reconstruction of the source AST.
That, I'm not sure if checking for matching initial offsets is sufficient to
create a semblance of a consistent structure definition. What will this code do
with structures like this:
struct S3 {
char x[3];
};
struct A {
union {
struct {
char c1;
S3 s1;
};
struct {
S3 s2;
char c2;
};
};
} a;
In this case, `a.s1` and `a.c2` overlap, but they don't share the same starting
offset. If the compiler does not provide data for anonymous structs as well,
then I think this algorithm will need to be more complicated. I'm not even sure
they can be reconstructed correctly, as the anonymous structs and unions can
nest indefinitely. Maybe it would be sufficient to represent this as a "union
of structs", where each struct gets (greedily) packed with as many members as
it can hold, and we create as many structs as we need (we can replace the
struct with a simple member if it would hold just one member)?
================
Comment at: lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.cpp:321
+ // the artificial anonymous union.
+ lldb::user_id_t au_id = LLDB_INVALID_UID - toOpaqueUid(m_id);
+ uint64_t au_field_bitoffset = 0;
----------------
How are these opaque ids computed? Will they produce unique IDs if you have two
structs like this close together? Might it be better to just make a global
(local to a symbol file or something) counter and always increment/decrement
that when creating another type ?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D134849/new/
https://reviews.llvm.org/D134849
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
