This sentence makes no sense, it was a remnant of a previous draft, which
included the option to do:
(lldb) platform write —field name —value expression —field other_name —value
other_expression
But that would require people to quote their expressions to get them past the
command parser, which
I would not do this with the expression parser.
First off, the expression parser doesn’t know how to do anything JIT code that
will run directly in the target. So if:
(lldb) expr $signinfo.some_field = 10
doesn’t resolve to some $siginfo structure in real memory with a real type such
that cla
On Tue, 2022-01-11 at 15:48 +, Ted Woodward wrote:
> You should use Hg for this instead of Hc. Hc is used for step/continue, while
> Hg is used for everything else.
>
Thanks for the explanation.
--
Best regards,
Michał Górny
___
lldb-dev mailing
You should use Hg for this instead of Hc. Hc is used for step/continue, while
Hg is used for everything else.
> -Original Message-
> From: lldb-dev On Behalf Of Michal Górny
> via lldb-dev
> Sent: Tuesday, January 11, 2022 6:38 AM
> To: lldb-dev@lists.llvm.org
> Subject: [lldb-dev] RFC
Hello,
TL;DR: I'd like to implement at least partial support for
reading/writing siginfo via LLDB. I can't think of a better approach
than copying the GDB's idea of "magical" $_siginfo variable that works
through the expression evaluator. I'd like to know your opinion/ideas.
POSIX defines a s
