Re: [lldb-dev] A bit of extra-polish for my lldb plugin
Because we try as much as possible to let the compiler figure this sort of thing out for us, we implement the transparent lookups for this & self by compiling our expression in a context that poses as a method of the class whose method we are stopped in. For instance, for ObjC, we construct a category on the class, and put the expression text in a method in that category, and then compile all that and call the method. That's done in ExpressionSourceCode::GetText. The one hitch to this is that this works because the compiler that is linked into lldb knows about the ObjC model we are emulating. An unmodified clang won't do transparent lookup into some random argument that happens to be called _param. So you would have to build lldb with a version of clang that understands your lookup rules for this to work. If that's not possible then you can try to do this by monkeying with the lookup rules implemented by lldb's ClangASTSource to return "_param.a" when it is just looking up "a". That's how we inject variables and types that are present in the local context into the expression as it is getting parsed. But at that point you are getting your hands into some fairly deep magic, and clang's Aslan is not as forgiving as Narnia's... Jim > On May 26, 2017, at 2:27 PM, Nat! via lldb-dev > wrote: > > Let me show you a snippet of a lldb debug session in progress in my ObjC > variant: > > ``` > -10,10,v,18.48 > Process 45774 stopped > * thread #1, queue = 'com.apple.main-thread', stop reason = step in >frame #0: 0x00010e2a multiple.debug`+[Foo > long:int:char:float:](self=Foo, _cmd=, > _param=0x7fff5fbff948) at multiple.m:15 > 12 char:(char) c > 13 float:(float) d > 14 { > 15 printf( "%ld,%d,%c,%.2f\n", a, b, c, d); > -> 16 } > 17 > 18 @end > (lldb) p *_param > (p.long:int:char:float:) $2 = (a = -10, b = 10, c = 'v', d = > 18.475) > ``` > > You can see that the parameter values `a,b,c,d` are actually fields of > a struct parameter `_param`. `_param` uniformly appears as the third > parameter after `self` and `_cmd`. `p _param->a` works of course, but it > would be nice to be able to say 'p a', since in the source code one sees > only `a`. `_param` is more or less an implementation detail. > > A clue how to achieve this, would be very much appreciated. > > Ciao > Nat! > > > [*] except, if it's a picture of thousand words :) > > https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_meta_call_convention.html > ___ > 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
[lldb-dev] A bit of extra-polish for my lldb plugin
Let me show you a snippet of a lldb debug session in progress in my ObjC variant: ``` -10,10,v,18.48 Process 45774 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = step in frame #0: 0x00010e2a multiple.debug`+[Foo long:int:char:float:](self=Foo, _cmd=, _param=0x7fff5fbff948) at multiple.m:15 12char:(char) c 13 float:(float) d 14 { 15 printf( "%ld,%d,%c,%.2f\n", a, b, c, d); -> 16 } 17 18 @end (lldb) p *_param (p.long:int:char:float:) $2 = (a = -10, b = 10, c = 'v', d = 18.475) ``` You can see that the parameter values `a,b,c,d` are actually fields of a struct parameter `_param`. `_param` uniformly appears as the third parameter after `self` and `_cmd`. `p _param->a` works of course, but it would be nice to be able to say 'p a', since in the source code one sees only `a`. `_param` is more or less an implementation detail. A clue how to achieve this, would be very much appreciated. Ciao Nat! [*] except, if it's a picture of thousand words :) https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_meta_call_convention.html ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Running lit (googletest) tests remotely
> On May 26, 2017, at 8:17 AM, Pavel Labath via llvm-dev > wrote: > > Hello all, > > we are trying to convert some of the lldb tests to lit (for these > specific tests we are using the googletest format). One of our > requirements is that we are able to run these tests remotely, so that > we are able to verify that we can debug e.g. android arm binaries even > though our development environment runs x86 linux). > > As far as I am aware, right now there is no support for that in lit: > running check-lldb-unit target in a cross-compile situation will > attempt to run the run the test binaries as if they were native and > fail horribly. > > Based on a not-too-detailed examination of the lit codebase, it does > not seem that it would be too difficult to add this capability: During > test discovery phase, we could copy the required files to the remote > host. Then, when we run the test, we could just prefix the run command > similarly to how it is done for running the tests under valgrind. It > would be up to the user to provide a suitable command for copying and > running files on the remote host (using rsync, ssh, telnet or any > other transport he chooses). This seems to be the crux to me: What does "required files" mean? - All the executables mentioned in the RUN line? What llvm was compiled as a library, will we copy those too? - Can tests include other files? Do they need special annotations for that? As another example: The llvm-testsuite can perform remote runs (test-suite/litsupport/remote.py if you want to see the implementation) that code makes the assumption that the remote devices has an NFS mount so the relevant parts of the filesystem look alike on the host and remote device. I'm not sure that is the best solution as NFS introduces its own sort of flakiness and potential skew in I/O heavy benchmarks but it avoids the question of what to copy to the device. - Matthias ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Documentation LLDB-MI
I see you also asked this on lldb-commits. This was a better list for that question, but I responded on the other list. In short, unless you need to use the MI because you have to support both gdb & lldb, I think you will be much happier using the SB API's than the MI. Jim > On May 26, 2017, at 3:42 AM, Laghzaoui Mohammed via lldb-dev > wrote: > > Hi Lists, > I have to implement a graphical interface to open the Dump of Macos with LLDB. > I know how to do this using the command line, but this and less productive, I > found that LLDB-MI little make me an interface to do this need but I did not > find an example of LLDB-MI in C ++ and How to build LLDB-MI. > To detail our need: > 1 - opening of a core dump. > 2 -__ reading the value of a memory address. > 3 -__ list threads and frames. > 4 -__ get assembler of each frame. > > Thank you in advance for your help > ___ > 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] Running lit (googletest) tests remotely
You might want to look at the compiler-rt tests, which have support for remote runs. Search for the '%run' substitution. It's probably not directly applicable to gtest tests, though. On Fri, May 26, 2017 at 8:17 AM, Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hello all, > > we are trying to convert some of the lldb tests to lit (for these > specific tests we are using the googletest format). One of our > requirements is that we are able to run these tests remotely, so that > we are able to verify that we can debug e.g. android arm binaries even > though our development environment runs x86 linux). > > As far as I am aware, right now there is no support for that in lit: > running check-lldb-unit target in a cross-compile situation will > attempt to run the run the test binaries as if they were native and > fail horribly. > > Based on a not-too-detailed examination of the lit codebase, it does > not seem that it would be too difficult to add this capability: During > test discovery phase, we could copy the required files to the remote > host. Then, when we run the test, we could just prefix the run command > similarly to how it is done for running the tests under valgrind. It > would be up to the user to provide a suitable command for copying and > running files on the remote host (using rsync, ssh, telnet or any > other transport he chooses). > > What do you think? Would something like that be a welcome addition to > the llvm testing infrastructure? Has anyone tried to do something like > that and hit major road blocks I did not anticipate? > > Or, if you have any suggestions on how to run tests in cross-compile > setting differently, I'd love to hear about them. > > regards, > pavel > ___ > 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
[lldb-dev] Running lit (googletest) tests remotely
Hello all, we are trying to convert some of the lldb tests to lit (for these specific tests we are using the googletest format). One of our requirements is that we are able to run these tests remotely, so that we are able to verify that we can debug e.g. android arm binaries even though our development environment runs x86 linux). As far as I am aware, right now there is no support for that in lit: running check-lldb-unit target in a cross-compile situation will attempt to run the run the test binaries as if they were native and fail horribly. Based on a not-too-detailed examination of the lit codebase, it does not seem that it would be too difficult to add this capability: During test discovery phase, we could copy the required files to the remote host. Then, when we run the test, we could just prefix the run command similarly to how it is done for running the tests under valgrind. It would be up to the user to provide a suitable command for copying and running files on the remote host (using rsync, ssh, telnet or any other transport he chooses). What do you think? Would something like that be a welcome addition to the llvm testing infrastructure? Has anyone tried to do something like that and hit major road blocks I did not anticipate? Or, if you have any suggestions on how to run tests in cross-compile setting differently, I'd love to hear about them. regards, pavel ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Documentation LLDB-MI
lldb-mi uses the gdb/mi interface, which is defined here: https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html . The lldb-mi implementation is slightly different in some ways, but nothing that should affect what you want to do. Looking at the code (in /tools/lldb-mi/MICmdCmdFile.cpp) for -file-exec-and-symbols, I don’t see a way to read a core file with mi commands, but you can give an lldb command that will be passed through, something like “target create foo.elf -c foo.core” You build lldb-mi the same way you build lldb, just use the lldb-mi target. For example, “make lldb-mi”. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Laghzaoui Mohammed via lldb-dev Sent: Friday, May 26, 2017 5:43 AM To: lldb-dev@lists.llvm.org Subject: [lldb-dev] Documentation LLDB-MI Hi Lists, I have to implement a graphical interface to open the Dump of Macos with LLDB. I know how to do this using the command line, but this and less productive, I found that LLDB-MI little make me an interface to do this need but I did not find an example of LLDB-MI in C ++ and How to build LLDB-MI. To detail our need: 1 - opening of a core dump. 2 -__ reading the value of a memory address. 3 -__ list threads and frames. 4 -__ get assembler of each frame. Thank you in advance for your help ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Documentation LLDB-MI
Hi Lists, I have to implement a graphical interface to open the Dump of Macos with LLDB. I know how to do this using the command line, but this and less productive, I found that LLDB-MI little make me an interface to do this need but I did not find an example of LLDB-MI in C ++ and How to build LLDB-MI. To detail our need: 1 - opening of a core dump. 2 -__ reading the value of a memory address. 3 -__ list threads and frames. 4 -__ get assembler of each frame. Thank you in advance for your help ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev