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
top level nodes
>> and organizes the commands under them is that adding new commands doesn’t
>> clutter up the top level of the command tree, and so you should feel free to
>> add new commands where they fit into the hierarchy rather than trying to
>> slide them
-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: siginfo reading/writing support
Hello,
TL;DR: I'd like to implement at least partial support for reading/writing
sig
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
t: Tuesday, January 11, 2022 6:38 AM
>> To: lldb-dev@lists.llvm.org
>> Subject: [lldb-dev] RFC: siginfo reading/writing support
>>
>> Hello,
>>
>> TL;DR: I'd like to implement at least partial support for reading/writing
>> siginfo
>> via LLDB. I
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
Subject: [lldb-dev] RFC: siginfo reading/writing support
>
> 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" $_si
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
12 matches
Mail list logo
