The other idea would be to allow the Platform subclasses to be able to fill in
some fixed variable names when asked.
So if the user typed either:
(lldb) frame variable $platform.siginfo
(lldb) expression $platform.siginfo
We would have the name lookup mechanism check with the current platform i
You are really going to make a lldb_private::CompilerType, since that’s what
backs the Type & ultimately the SBTypes. There’s a self-contained example
where we make a CompilerType to represent the pairs in the synthetic child
provider for NSDictionaries in the function GetLLDBNSPairType in
NSD
On Wed, 2022-01-12 at 11:22 -0800, Jim Ingham wrote:
> If we can’t always get our hands on the siginfo type, we will have to cons
> that type up by hand. But we would have had to do that if we were
> implementing this feature in the expression parser anyway, and we already
> hand-make types to
On Wed, 2022-01-12 at 11:22 -0800, Jim Ingham wrote:
>
> > On Jan 12, 2022, at 4:28 AM, Pavel Labath wrote:
> >
> > I kinda like the cleanliness (of the design, not the implementation) of a
> > $siginfo variable, but you're right that implementing it would be tricky (I
> > guess we'd have to w
On Wed, 2022-01-12 at 13:28 +0100, Pavel Labath wrote:
>
> This wouldn't solve the problem of writing to the siginfo struct, but I
> am not sure if this is a use case Michał is actually trying to solve
> right now (?) If it is then, maybe this could be done through a separate
> command, as we c
> On Jan 12, 2022, at 4:28 AM, Pavel Labath wrote:
>
> I kinda like the cleanliness (of the design, not the implementation) of a
> $siginfo variable, but you're right that implementing it would be tricky (I
> guess we'd have to write the struct info the process memory somewhere and
> then re
I kinda like the cleanliness (of the design, not the implementation) of
a $siginfo variable, but you're right that implementing it would be
tricky (I guess we'd have to write the struct info the process memory
somewhere and then read it back when the expression completes).
I don't expect that
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
11 matches
Mail list logo
