> Yeah, I think we can start with that.
No need to consider this now but it could easily be adapted to
qemu-system as well. Spinning up qemu-system for Cortex-M debug might
be a future use case. Once you've got a "run this program and connect
to this port" platform you can sub in almost anything
CC Nico
On Wed, 3 Nov 2021, Pavel Labath wrote:
[+ aleksandr]
On 03/11/2021 09:18, Martin Storsjö via lldb-dev wrote:
As far as I know, this is clearly the intended direction, but my
understanding is also that the native PDB plugin isn't quite on the same
functionality level yet.
While
[+ aleksandr]
On 03/11/2021 09:18, Martin Storsjö via lldb-dev wrote:
On Tue, 2 Nov 2021, Raphael Isemann via lldb-dev wrote:
Unless removing the non-native PDB plugin has some negative impact on
users (e.g., missing features in native plugin that work with the
non-native plugin), I would
On 29/10/2021 14:55, David Spickett wrote:
I don't think it does. Or at least I'm not sure how do you propose to solve them (who is
"you" in the paragraph above?).
I tend to use "you" meaning "you or I" in hypotheticals. Same thing as
"if I had" but for whatever reason I phrase it like that
Try target.AttachToProcessWithID() instead of target.LaunchSimple().
LaunchSimple tells lldb to run, creating a new process, instead of attaching to
an existing one. See the SBTarget Python documentation here:
https://lldb.llvm.org/python_reference/lldb.SBTarget-class.html .
You should also be
On Tue, 2 Nov 2021, Raphael Isemann via lldb-dev wrote:
Unless removing the non-native PDB plugin has some negative impact on
users (e.g., missing features in native plugin that work with the
non-native plugin), I would propose we delete it and only keep the
native PDB plugin in LLDB which
