https://github.com/DavidSpickett edited
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
https://github.com/DavidSpickett edited
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
https://github.com/DavidSpickett updated
https://github.com/llvm/llvm-project/pull/90059
>From 6344ce3feff235f6a3b1bc1d5eb1e50e5695d320 Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Mon, 11 Mar 2024 10:18:51 +
Subject: [PATCH] [lldb] Add format eFormatEnumWithValues to ensure raw
DavidSpickett wrote:
>So each ValueObject has the ability to show its value as an enumeration if its
>format is set to eFormatEnum. If the format is set to eFormatHex,
>eFormatUnsigned, or eFormatSigned, then we show the numeric value.
Sure, the problem I have is that often with registers
clayborg wrote:
If your register has fields, you can set its format to be eFormatEnum by
default. Each register defines how it gets displayed when we query the dynamic
register information from the `lldb-server` or `debugserver`
https://github.com/llvm/llvm-project/pull/90059
https://github.com/clayborg requested changes to this pull request.
So each `ValueObject` has the ability to show its value as an enumeration if
its format is set to `eFormatEnum`. If the format is set to `eFormatHex`,
`eFormatUnsigned`, or `eFormatSigned`, then we show the numeric value.
DavidSpickett wrote:
I found a few things:
* Yes you can get these flags like enums with a register field as expected.
* Only C++ code can manipulate a `DumpValueObjectOptions` object, there's no
Python binding at all.
* The only Python tests for it are things that call commands that then use
DavidSpickett wrote:
I understand, so the value is made from `a | b | c` for example. I didn't think
of whether register fields could hit this path, but it's equivalent to a C enum
they'll be using, so I think it could happen.
I'll test this, thanks for bringing it up.
Endilll wrote:
> For me the picture is limited to register printing. I'll be setting this new
> option on the register type when printing
>
DavidSpickett wrote:
> It's also not clear how this new "presentation mode" is going to be
> controlled. While it's not in the scope of this PR, it would be nice if you
> can share a bigger picture.
For me the picture is limited to register printing. I'll be setting this new
option on the
Endilll wrote:
I'm excited so see changes in this area!
> It is a subset of https://github.com/llvm/llvm-project/pull/69815, only for
> use by register printing (ping @Endilll).
Yeah, that effort is stalled because I don't see a clear path forward there,
and I'm lacking energy to find and
DavidSpickett wrote:
This is the first change for
https://discourse.llvm.org/t/rfc-adding-register-field-enums-to-lldb/77275,
though there has been a change of plans and now I'm implementing existing GDB
features to get the same result.
It is a subset of
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: David Spickett (DavidSpickett)
Changes
When an enum is used to represent certain data it can be useful to know its
name and the value of it. For instance, register fields are often set in source
code as numbers, but in the debugger you'd
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/90059
When an enum is used to represent certain data it can be useful to know its
name and the value of it. For instance, register fields are often set in source
code as numbers, but in the debugger you'd like
14 matches
Mail list logo
