Re: [lldb-dev] LLDB Process Attach Failed When Waiting
On Tue, 5 Jun 2018 at 01:18, Ryan Lovelett via lldb-dev wrote: > > So I've found a capability on Linux to be notified about new processes. I > have an example of listening for these new processes running on my machine > now [1] and I can see when my desired user process spawns. Though > documentation on the API is scarce. It also requires that the executable or > user have the CAP_NET_ADMIN capability to run. > > It's possible that the addition of this requirement is a non-starter. Though > I'm not 100% sure. Do you have any thoughts before I pursue this further? I doubt anybody will be installing lldb with elevated privileges, and I would be wary of recommending that. Theoretically, we could implement that approach and use it in case the user happens to have that privilege, but I don't believe it's worth it. I think we should just stick to the polling approach. You should be able to get a list of running processes with `Host::FindProcesses`. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLVM-C
Hi, On 5 June 2018 at 03:13, Giannis Zamanis via lldb-dev wrote: > I have tried using zero-sized type array as > the typical parameter in the function definition, but when i call the > function with a normal-sized array as argument it throws error due to > mismatch in types. I can't find a workaround for this. You'll need a bitcast. Either bitcast your %only_l (a [20 x i32]*) to [0 x i32]* or bitcast your function @ha so that it can accept a [20 x i32]*. The first is probably simpler to implement, but both should work. Cheers. Tim. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] error printed to stderr: "Could not find implementation lookup function...."
This error gets printed for all Darwin programs that are not objective C and is
quite annoying in AppleObjCTrampolineHandler.cpp:
if (m_impl_fn_addr == LLDB_INVALID_ADDRESS) {
// If we can't even find the ordinary get method implementation function,
// then we aren't going to be able to
// step through any method dispatches. Warn to that effect and get out of
// here.
if (process_sp->CanJIT()) {
process_sp->GetTarget().GetDebugger().GetErrorFile()->Printf(
"Could not find implementation lookup function \"%s\""
" step in through ObjC method dispatch will not work.\n",
get_impl_name.AsCString());
}
return;
} ...
Can we quiet this error when libobjc isn't loaded? Our IDE prints out anything
it gets on stderr and this error always has people worried there is something
wrong.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] error printed to stderr: "Could not find implementation lookup function...."
Greg,
Something is going wrong here before you get to this point. You can't get to
the code in question (creating the AppleObjCTrampolineHandler) if you don't
have an ObjCLanguageRuntime of some sort. The only way the trampoline gets
made is in ReadObjCLibrary, which is a pure virtual method on
ObjCLanguageRuntime, so somebody had to successfully made an
ObjCLanguageRuntime.
However, the CreateInstance for the concrete ObjCLanguageRuntimes calls
AppleObjCRuntime::GetObjCVersion and then checks that the version is the right
one for the V1 or V2 implementations. That will only return something
different from eObjC_VersionUnknown if a scan over the loaded modules finds one
for which AppleObjCRuntime::AppleIsModuleObjCLibrary returns true. But that
just checks that libobjc.A.dylib is in the target list.
So I don't see how you can get to this error if you don't have libobjc.A.dylib
loaded. OTOH, I don't know how you are seeing a libobjc.A.dylib that doesn't
have class_getMethodImplementation in it...
BTW:
(lldb) b s -p return
Breakpoint 1: where = hello`main + 13 at hello.c:6, address = 0x00010fad
(lldb) run
Process 56377 launched: '/tmp/hello' (x86_64)
Process 56377 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00010fad hello`main at hello.c:6
3int
4main()
5{
-> 6 return 0;
^
7}
Target 0: (hello) stopped.
(lldb) image list libobjc.A.dylib
[ 0] DD9E5EC5-B507-3249-B700-93433E2D5EDF 0x7fff5093f000
/usr/lib/libobjc.A.dylib
So I'm also not sure it is possible to make a darwin binary that doesn't load
libobjc.A.dylib.
Jim
> On Jun 5, 2018, at 1:20 PM, Greg Clayton wrote:
>
> This error gets printed for all Darwin programs that are not objective C and
> is quite annoying in AppleObjCTrampolineHandler.cpp:
>
>
>
> if (m_impl_fn_addr == LLDB_INVALID_ADDRESS) {
>// If we can't even find the ordinary get method implementation function,
>// then we aren't going to be able to
>// step through any method dispatches. Warn to that effect and get out of
>// here.
>if (process_sp->CanJIT()) {
> process_sp->GetTarget().GetDebugger().GetErrorFile()->Printf(
> "Could not find implementation lookup function \"%s\""
> " step in through ObjC method dispatch will not work.\n",
> get_impl_name.AsCString());
>}
>return;
> } ...
>
>
> Can we quiet this error when libobjc isn't loaded? Our IDE prints out
> anything it gets on stderr and this error always has people worried there is
> something wrong.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] MacOS minidump debugging
Hi, lldb newbie here. Has anyone debugged minidump with lldb in MacOS. Any documentation or pointers would be appreciated! Thanks, Rustam ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] MacOS minidump debugging
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 minidump with lldb in MacOS. Any documentation or > pointers would be appreciated! > > Thanks, > Rustam > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB Process Attach Failed When Waiting
I think I might be a little lost. I built a lldb in debug mode and I am
running lldb in an lldb debugger (very meta).
Earlier in the thread you said "we need a better error message when
vAttachWait returns unsupported" I have found where the error message,
e.g., "error: attach failed: lost connection" is constructed. The
"attach failed: " comes from here [1] and the "lost connection" comes
from here [2].
What do you mean by "vAttachWait"? Am I missing something obvious?
It seems like you are expecting lldb-server to be the place where the
fix will be implemented. Though in the debugger I'm seeing the method
Target::Attach() [3] as the place where the connection attempt is made
and fails.
[1]
https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Commands/CommandObjectProcess.cpp#L518[2]
https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3444-L3445[3]
https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3374
On Mon, Jun 4, 2018, at 7:04 PM, Greg Clayton wrote:
> I will be too busy this week to get to this, so please do have a
> stab at it.>
> Basically the flow that debug server does is:
> 1 - get a list of all processes whose basename matches and remember
> those pids so we don't try to attach to them since we are waiting for
> a new process to show up> 2 - poll the OS for the process list and wait for a
> new pid to show up
> with the basename and attach to the first one that matches whose pid
> isn't i the list from step #1>
> On MacOSX we don't have a way to be notified of new processes are
> spawned, not sure on other unix variants. If it is possible, we would
> want change to:> 1 - sign up to be notified about new processes
> 2 - as each process gets launched, check for a match and attach as
> quickly as possible>
> Hope this helps and I look forward to seeing your patch!
>
> Greg
>
>> On Jun 4, 2018, at 5:56 AM, Ryan Lovelett wrote:
>>
>> Greg,
>>
>> Is there anything I can do to help you implement or test this
>> feature? Obviously I'm willing to roll-up my sleeves and work on this
>> myself too if you've become more busy than you expected. That happens
>> to us all and I completely understand.>>
>> Not being able to debug in this manner is blocking me from adding
>> Linux support to a Swift program. As you might imagine, I'm a little
>> antsy to get past this so I can start writing some code.>>
>> On Thu, May 31, 2018, at 5:08 PM, Greg Clayton wrote:
>>>
>>>
On May 31, 2018, at 12:40 PM, Ryan Lovelett
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/ ? 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
>> 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 "" --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
Re: [lldb-dev] LLDB Process Attach Failed When Waiting
Except for Windows and FreeBSD, lldb uses a server program to do the actual debugging - either debugserver on Darwin or lldb-server elsewhere. The interface to these servers (and to the in-process debugging in Windows & FreeBSD) is abstracted being Process Plugins, which the generic code uses. Target::Attach is in generic code, it won't know anything about the actual method used to attach, wait for attach, whatever. That will be dispatched to the currently active ProcessPlugin. ProcessGDBRemote is the plugin that is used on Linux & Darwin. It is the code that actually talks to debugserver or lldb-rpc-server from within lldb. And that's the code in lldb that sends the vAttachWait gdb-remote protocol packet to instruct the above-mentioned servers to implement attach-wait. That request works on Darwin because debugserver handles the vAttachWait packet, but doesn't work on Linux because lldb-rpc-server doesn't know currently respond to the vAttachWait packet. So all you should need to do is teach lldb-server to handle the vAttachWait packet. Jim > On Jun 5, 2018, at 5:44 PM, Ryan Lovelett via lldb-dev > wrote: > > I think I might be a little lost. I built a lldb in debug mode and I am > running lldb in an lldb debugger (very meta). > > Earlier in the thread you said "we need a better error message when > vAttachWait returns unsupported" I have found where the error message, e.g., > "error: attach failed: lost connection" is constructed. The "attach failed: " > comes from here [1] and the "lost connection" comes from here [2]. > > What do you mean by "vAttachWait"? Am I missing something obvious? > > It seems like you are expecting lldb-server to be the place where the fix > will be implemented. Though in the debugger I'm seeing the method > Target::Attach() [3] as the place where the connection attempt is made and > fails. > > [1] > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Commands/CommandObjectProcess.cpp#L518 > [2] > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3444-L3445 > [3] > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3374 > > On Mon, Jun 4, 2018, at 7:04 PM, Greg Clayton wrote: >> I will be too busy this week to get to this, so please do have a stab at it. >> >> Basically the flow that debug server does is: >> 1 - get a list of all processes whose basename matches and remember those >> pids so we don't try to attach to them since we are waiting for a new >> process to show up >> 2 - poll the OS for the process list and wait for a new pid to show up with >> the basename and attach to the first one that matches whose pid isn't i the >> list from step #1 >> >> On MacOSX we don't have a way to be notified of new processes are spawned, >> not sure on other unix variants. If it is possible, we would want change to: >> 1 - sign up to be notified about new processes >> 2 - as each process gets launched, check for a match and attach as quickly >> as possible >> >> Hope this helps and I look forward to seeing your patch! >> >> Greg >> >>> On Jun 4, 2018, at 5:56 AM, Ryan Lovelett wrote: >>> >>> Greg, >>> >>> Is there anything I can do to help you implement or test this feature? >>> Obviously I'm willing to roll-up my sleeves and work on this myself too if >>> you've become more busy than you expected. That happens to us all and I >>> completely understand. >>> >>> Not being able to debug in this manner is blocking me from adding Linux >>> support to a Swift program. As you might imagine, I'm a little antsy to get >>> past this so I can start writing some code. >>> >>> On Thu, May 31, 2018, at 5:08 PM, Greg Clayton wrote: > On May 31, 2018, at 12:40 PM, Ryan Lovelett 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/ ? 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: >>
Re: [lldb-dev] LLDB Process Attach Failed When Waiting
Thank you that was a huge help. I'm making some progress now. Though I wonder, is there any documentation of the GDB packet format? The reason I ask is that I'm trying to figure out to get the process name from vAttach. I've looked at how debugserver does it, namely the method GetProcessNameFrom_vAttach [1], and I cannot seem to find the equivalent method in StringExtractorGDBRemote or StringExtractor (though I'll admit that it might be obvious and I'm just missing it). If that's the case I imagine I'll have to implement it and I would like to at least understand the packet format to do that. [1] https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/tools/debugserver/source/RNBRemote.cpp#L3585 On Tue, Jun 5, 2018, at 9:03 PM, Jim Ingham wrote: > Except for Windows and FreeBSD, lldb uses a server program to do the > actual debugging - either debugserver on Darwin or lldb-server > elsewhere. The interface to these servers (and to the in-process > debugging in Windows & FreeBSD) is abstracted being Process Plugins, > which the generic code uses. Target::Attach is in generic code, it > won't know anything about the actual method used to attach, wait for > attach, whatever. That will be dispatched to the currently active > ProcessPlugin. > > ProcessGDBRemote is the plugin that is used on Linux & Darwin. It is > the code that actually talks to debugserver or lldb-rpc-server from > within lldb. And that's the code in lldb that sends the vAttachWait > gdb-remote protocol packet to instruct the above-mentioned servers to > implement attach-wait. That request works on Darwin because debugserver > handles the vAttachWait packet, but doesn't work on Linux because lldb- > rpc-server doesn't know currently respond to the vAttachWait packet. So > all you should need to do is teach lldb-server to handle the vAttachWait > packet. > > Jim > > > > On Jun 5, 2018, at 5:44 PM, Ryan Lovelett via lldb-dev > > wrote: > > > > I think I might be a little lost. I built a lldb in debug mode and I am > > running lldb in an lldb debugger (very meta). > > > > Earlier in the thread you said "we need a better error message when > > vAttachWait returns unsupported" I have found where the error message, > > e.g., "error: attach failed: lost connection" is constructed. The "attach > > failed: " comes from here [1] and the "lost connection" comes from here [2]. > > > > What do you mean by "vAttachWait"? Am I missing something obvious? > > > > It seems like you are expecting lldb-server to be the place where the fix > > will be implemented. Though in the debugger I'm seeing the method > > Target::Attach() [3] as the place where the connection attempt is made and > > fails. > > > > [1] > > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Commands/CommandObjectProcess.cpp#L518 > > [2] > > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3444-L3445 > > [3] > > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3374 > > > > On Mon, Jun 4, 2018, at 7:04 PM, Greg Clayton wrote: > >> I will be too busy this week to get to this, so please do have a stab at > >> it. > >> > >> Basically the flow that debug server does is: > >> 1 - get a list of all processes whose basename matches and remember those > >> pids so we don't try to attach to them since we are waiting for a new > >> process to show up > >> 2 - poll the OS for the process list and wait for a new pid to show up > >> with the basename and attach to the first one that matches whose pid isn't > >> i the list from step #1 > >> > >> On MacOSX we don't have a way to be notified of new processes are spawned, > >> not sure on other unix variants. If it is possible, we would want change > >> to: > >> 1 - sign up to be notified about new processes > >> 2 - as each process gets launched, check for a match and attach as quickly > >> as possible > >> > >> Hope this helps and I look forward to seeing your patch! > >> > >> Greg > >> > >>> On Jun 4, 2018, at 5:56 AM, Ryan Lovelett wrote: > >>> > >>> Greg, > >>> > >>> Is there anything I can do to help you implement or test this feature? > >>> Obviously I'm willing to roll-up my sleeves and work on this myself too > >>> if you've become more busy than you expected. That happens to us all and > >>> I completely understand. > >>> > >>> Not being able to debug in this manner is blocking me from adding Linux > >>> support to a Swift program. As you might imagine, I'm a little antsy to > >>> get past this so I can start writing some code. > >>> > >>> On Thu, May 31, 2018, at 5:08 PM, Greg Clayton wrote: > > > > On May 31, 2018, at 12:40 PM, Ryan Lovelett wrote: > > > > Well at least there is a little good news. I understood way more of > > those logs than I thought I did. >
