In LLDB you can always return "05" as the signal number (which is SIGTRAP), but
then fill in the other key/value types in the stop reply packet. GDB solely
relies on the signal numbers, LLDB doesn't.
See the section named "Stop reply packet extensions" in the gdb protocol doc we
have:
svn cat
Yeah, we have to fake the numbers, we have some sort of dummy mapping
that converts Windows events to the UNIX equivalent that makes the
most sense. It's kind of dumb, but that's the only thing that LLDB or
gdb support.
First half of the conversion is here:
https://github.com/facebook/ds2/blob/mas
I'm curious, can you share how did you deal with the fact that the
gdb-remote protocol is very signal-centric? E.g. every stop-reply ($T) has
to have a specific signal associated with it, and some signals have special
meaning in lldb. Do you just fake the signal numbers when you need to? Or
is the
For what it's worth, we've been using lldb with ds2 to do remote
debugging on Windows (x86) and Windows Phone (arm) and the lldb side
of things works well with remote Windows targets. Besides porting
lldb-server to Windows there shouldn't be any extra effort on the lldb
side to do what Greg is talk
> On Nov 29, 2016, at 10:16 PM, Zachary Turner wrote:
>
> What would it take to make it so that local and remote process plugins use
> the same exact interface? I mean in theory they're doing the same thing,
> just on a different machine. If they shared an identical interface then you
> cou
What would it take to make it so that local and remote process plugins use
the same exact interface? I mean in theory they're doing the same thing,
just on a different machine. If they shared an identical interface then
you could hook the lldb-server up to it and it would work either locally or
r
I have no objection to moving in that direction (enabling remote
debugging). Zach just pointed out that we'd first have to port lldb-server
to Windows. Offhand, I don't know how much of an effort that would be.
In the near-term, I'm focused on postmortem debugging, so this wouldn't be
a priority
One thing that we have talked about is to move the ProcessWindows stuff into
lldb-server (it has a NativeProcess and NativeThread class you would need to
subclass instead of making ProcessWindows and ThreadWindows classes) instead of
making a native plug-in that is only useful on the current sys
