DavidSpickett wrote: > When you display registers bitfields do you have a ValueObject?
Yes: https://github.com/llvm/llvm-project/blob/6808e6c78edf63d2c0c9bd6fce168fe7e0a7d49f/lldb/source/Core/DumpRegisterValue.cpp#L47 I'm just calling `dump`, there's no register specific code there, ideally I wouldn't need any. > If so we can modify the ValueObject::GetSummary() to return the integer > value, but only if we have the format set to eFormatEnum. The output for > variables would be similar to what your tests expect, but we would just > modify the summary string that we return and then we don't need the new > format. I am not sure if a call to `dump` will end up using `GetSummary` or whether I'd need to loop over the children of the object myself, I'll look into it. > One reason I like this way of doing things is if you call > "valobj.GetValue()", and the format is set the enum with value, we will get > "foo (1)" as the value back from the value object. I would rather call > valobj.GetValue() and get "foo" and then call valojb.GetSummary() and get "1" When you put it like API style calls like that, I agree. `foo` is a "value" in the sense you could write it in your C source, `foo (1)` is not, it is literally a summary, an overview of the value, not usable in code. > If we have special display code for the register bitfields, they can call > these APIs when displaying register by default? By using the existing type infrastructure I avoided having to write printer code, so there isn't any right now. You could sort of do this by having options that only C++ code can set and are only used by the register dump code, this is what the original version of this PR did (which you can see [here](https://github.com/DavidSpickett/llvm-project/commit/cb875625d7159857345e3da2b9aa4f2436134bee) to compare). It's not great because it is this one off use case, but at least it's hidden from the command line and API users. Or I could add some kind of callback that only register dumping sets, that asks how to format the enum, but this is the same thing with different steps. Could wait and see if registers need anything else unique, and once enough of that exists, invest in custom code. After all, users can `register info` to see the values for an enum, and only a minority will need them anyway. ...and an off the wall idea I just thought of. These register types are only for display, and we could generate different ones for expressions (https://discourse.llvm.org/t/rfc-register-fields-in-expressions/79424) if needed. So instead of using `enum` for the field why not a `union` of `enum` and `unsigned`. The printed format might not be obvious to the reader but I'll give it a try, as it would sidestep the problems of the other solutions. https://github.com/llvm/llvm-project/pull/90059 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
