> On May 31, 2018, at 12:40 PM, Ryan Lovelett <r...@lovelett.me> wrote:
>
> Well at least there is a little good news. I understood way more of those
> logs than I thought I did.
>
>> So two issues here:
>> 1 - we need a better error message when vAttachWait returns unsupported
>> 2 - fix lldb-server to support vAttachWait
>
> A few questions.
>
> What is the protocol here? Can/should I report the issues at
> https://bugs.llvm.org/ <https://bugs.llvm.org/> ? Or is that something that a
> project member needs to do? Assuming that I can, would this be two seperate
> issues or one "large" issue?
>
> Barring that this is not something someone else might implement better/faster
> than me. Considering I have zero LLDB development experience is this
> something that I could tackle?
I didn't realize this functionality was missing in lldb-server. I can take a
stab at implementing it and see what I can do. Stay tuned.
>
> On Thu, May 31, 2018, at 3:02 PM, Greg Clayton wrote:
>> lldb-server claims it doesn't support it:
>>
>> lldb < 48> send packet:
>> $vAttachWait;6c616e677365727665722d7377696674#d6
>> lldb < 4> read packet: $#00
>>
>>
>> Returning the empty packet ("$#00") means it is not supported, but we really
>> should give a better error message than this.
>>
>> It isn't that hard to implement. It would be easy to copy the code that is
>> in debugserver in DNB.cpp in the DNBProcessAttachWait function. Most of it
>> is probably posix style stuff.
>>
>> So two issues here:
>> 1 - we need a better error message when vAttachWait returns unsupported
>> 2 - fix lldb-server to support vAttachWait
>>
>> Greg
>>
>>
>>> On May 31, 2018, at 11:04 AM, Ryan Lovelett <r...@lovelett.me
>>> <mailto:r...@lovelett.me>> wrote:
>>>
>>>> It might be a lldb-server issue?
>>>
>>> How would one go about determining this?
>>>
>>> (lldb) log enable -f /tmp/packates.txt gdb-remote packets
>>> (lldb) process attach --name "<name>" --waitfor
>>> error: attach failed: lost connection
>>>
>>> Attached the log output. Maybe it'll make more sense to you than me.
>>>
>>> That escalated quickly. So I've read through that log. I found something
>>> that says $qVAttachOrWaitSupported#38 with the following response being
>>> $#00. Perhaps I'm reading too much but is it that it's reporting that it is
>>> not supported?
>>>
>>> Does lldb-server need to be compiled in a certain way to add support for
>>> attach wait?
>>>
>>> On Thu, May 31, 2018, at 1:49 PM, Greg Clayton wrote:
>>>> Try enabling logging with:
>>>>
>>>> (lldb) log enable -f /tmp/packets.txt gdb-remote packets
>>>>
>>>> And the try the attach. It might be a lldb-server issue?
>>>>
>>>>> On May 31, 2018, at 9:02 AM, Ryan Lovelett via lldb-dev
>>>>> <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote:
>>>>>
>>>>> I am attempting to use: process attach --name "<name>" --waitfor
>>>>>
>>>>> The problem is that it immediately returns error: attach failed: lost
>>>>> connection.
>>>>>
>>>>> Is this something I can troubleshoot further? Or is this not supported on
>>>>> Linux?
>>>>>
>>>>> --
>>>>> Ryan Lovelett
>>>>> _______________________________________________
>>>>> lldb-dev mailing list
>>>>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>> <packates.txt>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
