[PATCH] D72557: Add pretty printers for llvm::PointerIntPair and llvm::PointerUnion.

[Christian Sigg via Phabricator via llvm-commits]

csigg marked an inline comment as done.
csigg added inline comments.


================
Comment at: llvm/utils/gdb-scripts/prettyprinters.py:324
+    try:
+      name = val.type.template_argument(3).name + '::NumLowBitsAvailable'
+      bits_available = gdb.parse_and_eval(name)
----------------
dblaikie wrote:
> csigg wrote:
> > dblaikie wrote:
> > > Any chance of avoiding stringification/parsing here? could this be written as val.type.template_argument(3)['NumLowBitsAvailable'] instead? (I'm guessing not, but figured I'd check)
> > > 
> > > Oh, looks like maybe that does work: https://sourceware.org/gdb/current/onlinedocs/gdb/Types-In-Python.html - though it seems maybe gdb.Fields can only provide their value if they're an enum (enumval), maybe not if they're static? Even if the final name has to be stringified and eval'd - it'd still be nice to avoid string concatenation to create the name, if reasonably feasible.
> > > 
> > > 
> > Do you know if `gdb.lookup_symbol(<string>).value()` would be any better than `gdb.parse_and_eval(<string>)`?
> > 
> > I experimented for a while (disclaimer: I'm a Python GDB newbie) but couldn't get the enum to show up in PtrTraits.fields(), no matter whether the enum is named or anonymous. 
> > However, the named enum can be found with `gdb.lookup_type()`, and the fields() do contain the enumerators. That would be the third option.
> > 
> > 
> > 
> > 
> > 
> Sorry, the mention of enums was a red herring - not related to the existing enum usage here, but just something that was in the docs.
> 
> Nah, gdb.lookup_symbol(<string>).value() V gdb.parse_and_eval(<string>) doesn't make much difference to me.
> 
> Just looking at the constexpr static int member version of the code, not the enum - is there a way to avoid stringification to build the name of the constant? Can the static member variable be found in the fields list of the class? & then evaluated?
There is no way to get to the static members of a struct without stringification, only enumerators of an enum.

Enums are no win because getting to the nested enum requires gdb.lookup_type(<stringification>). It would require a standardized enum name.

Instantiating the traits or info class (e.g. as empty base class) to get to the static member would add the requirement that PointerTy is complete. That seems worse.

I'm out of ideas for other approaches.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72557/new/

https://reviews.llvm.org/D72557