[Lldb-commits] [PATCH] D49410: [PDB] Parse UDT symbols and pointers to members

[Zachary Turner via lldb-commits]

Wouldn’t the location of the unnamed struct be the location of its first
member? We already print the offsets of the individual members, so that
part is solvable (although that code is horrendously complex). The second
part is figuring out how to correlate the member back to the unnamed struct
it came from. If you can find the unnamed struct by enumerating children of
S, this isn’t too bad. S has a data member named a and a child unnamed
struct with a member named a, therefore they must be the same a. If the
unnamed struct doesn’t show up when enumerating children though, then I’m
not sure .
On Wed, Jul 25, 2018 at 4:28 AM Aleksandr Urakov via Phabricator <
reviews at reviews.llvm.org> wrote:

> aleksandr.urakov added a comment.
>
> In https://reviews.llvm.org/D49410#1174787, @zturner wrote:
>
> > When you have a DIA interface for struct S, can you just call
> >  findChildren<PDBSymbolTypeUDT>()? Will that enumerate tge unnamed
> struct?
>
>
> I have checked this again with `cl` and `clang-cl` (but I have enumerated
> all children, not only UDTs). For the cl-emitted PDB there are only `Data`
> children (for fields `a`, `b`, `c`, `d` and `e`). The clang-emitted PDB
> also contains all the `Data` children, but it also contains two unnamed UDT
> children (for the unnamed struct and the unnamed union). I.e. `clang` emits
> more info than `cl`.
>
> But I can't understand, how will this info help us to resolve two points
> I've mentioned in the previous message? Can you explain, please?
>
> Thanks!
>
> > The fact that pdbutil doesn’t is only an indication of how the printing
> >  code behaves, you shouldn’t interpret anything about what information is
> >  available from it
>
>
> https://reviews.llvm.org/D49410
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20180725/a8efd3aa/attachment.html>