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 < revi...@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 > > > >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
