Hey everyone,
I'm proposing an LLDB BoF at the upcoming LLVM developer meeting. Currently
I have a pretty generic abstract, but I think it would be good to have a
more concrete agenda.
> LLDB has seen an influx of contributions over the past year, with the
highest level of activity we've seen in
We'll be at Tied House as usual, starting on Thursday the 11th at 7pm!
If you can, help us plan and RSVP here:
https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyzkbgb/
See everyone there!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https:/
Thanks for looking into this, Jason. I ended up realizing that it isn't
about the number of evaluations; it is the exact location of the
breakpoints that matters.
I'm being able to consistently reproduce this by having two breakpoints (A
and B) inside the same function, but B being inside the scop
It looks like you don't have a DynamicLoader plugin that tells lldb where your
binaries ended up in memory when the process ran. The [ADDRESS] means we are
reading instructions from memory not from the on-disk binary.
Jim
> On Jul 9, 2019, at 2:14 AM, Romaric Jodin via lldb-dev
> wrote:
>
HI everyone,
I'm adding my architecture into lldb.
I'm having some trouble with the debug information on the stack frame.
LLDB is never displaying any source code. It seems that we I get in
"StackFrame::GetSymbolContext" "m_flags" is always set to "0x" but
my "m_sc" does not contains the i
