I'm attaching the first cut of the patch that I think is worth sharing for
feedback. There is more work to do with regard to documentation and tests. Any
feedback is appreciated.
I am going to do my best and follow the steps listed in the "LLVM Developer
Policy" as this continues forward.
Greg
> Sleep is used to make the system sleep the current thread a little bit
> between polling for processes by name. If the sleep isn't there, we will
> light up a CPU with really quick polling for the processes by name, so
> we should use usleep() which take a sleep amount in microseconds to not
> On Jun 6, 2018, at 2:20 PM, Ryan Lovelett wrote:
>
> Huzzah! I have a working proof of concept.
>
> A few more questions (I hope I'm not wearing out my welcome):
We are very happy to see this feature coming along, so no worries. Ask as many
questions as you need!
>
> 1. There seems to be
Huzzah! I have a working proof of concept.
A few more questions (I hope I'm not wearing out my welcome):
1. There seems to be a "sleep" capability in the DNBProcessAttachWait method
[1]. I'm not exactly sure how this "sleep" function works. When I use it the
sleep seems to be a no-op. Is there
We don't have support for reading mac minidumps presently. That said,
it probably wouldn't be too hard to add one, as we already have
windows and linux minidumps working (to some degree, at least). It
would probably require adding parsing support for some OS-specific
structures (I recall some thing
Yes.
On Tue, Jun 5, 2018 at 7:33 PM, Zachary Turner wrote:
> I assume you're referring to a windows minidump as opposed to a Mac core
> file?
>
> On Tue, Jun 5, 2018 at 4:19 PM Rustam Hashimov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi,
>> lldb newbie here.
>> Has anyone debugged m
There are other options available as well, but for this particular
scenario, I'd go with the following:
- start debugging the client, set a breakpoint just before it sends
the vAttach packet
- when the client reaches this breakpoint, attach a debugger to the
server (it will already be running at th
Does anyone have any specific suggestions on how I might go about
debugging/testing this? Specifically, turning on the logging in the gdb-server
and also launching lldb-server separate from lldb so that I can actually attach
a debugger to it.
My workflow right now is to start the gdb-server lik
Thank you. That get me moving again. I will also see if there is anything I
could contribute to lldb-gdb-remote.txt regarding the format of this packet.
On Wed, Jun 6, 2018, at 3:59 AM, Pavel Labath wrote:
> There is some documentation on the packets in docs/lldb-gdb-remote.txt
> in the lldb repo
There is some documentation on the packets in docs/lldb-gdb-remote.txt
in the lldb repo, though for this particular packet it does not say
much about the encoding (patches welcome).
That said, it looks like the format is just that we send the process
name hex-encoded. For that you can simply use
S
10 matches
Mail list logo
