Re: [lldb-dev] A bit of extra-polish for my lldb plugin

[Jim Ingham via lldb-dev]

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

[Nat! via lldb-dev]

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

[Matthias Braun via lldb-dev]

> 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

[Jim Ingham via lldb-dev]

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

[Reid Kleckner via lldb-dev]

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

[Pavel Labath via lldb-dev]

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

[Ted Woodward via lldb-dev]

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

[Laghzaoui Mohammed via lldb-dev]

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