I've published a short report for the previous milestone, with goals for
the ongoing one.
"The first patch-bulk upstreamed to LLDB"
http://blog.netbsd.org/tnf/entry/the_first_patch_bulk_upstreamed
The next one will turn to be more exciting as I plan to start with
implementation of accessors f
These issues should be resolved by r295013 and r295014.
On Thu, Feb 9, 2017 at 1:55 PM, Hans Wennborg wrote:
> I'm happy as long as it builds :-)
>
> On Wed, Feb 8, 2017 at 2:26 PM, Zachary Turner wrote:
> > Should we do that now, as a way to fix this issue, or should we try to
> get
> > anothe
Thank you very much Greg and Pavel for help!
I will probably need another months or so to work on my variable tracing
stuff. I don't see any additional roadblocks yet.
2017-02-13 22:11 GMT+03:00 Greg Clayton :
> Clang just doesn't currently know where to look for the standard headers.
> Not sure
I've noticed that apt created some invalid symlinks, but fixing them did
not helped. I have a gut feeling that the problem is with prebuilt packages
from http://apt.llvm.org/ , not with lldb sources .
But we need someone else with Ubuntu 16.04 to confirm.
2017-02-13 22:15 GMT+03:00 Greg Clayton :
Works for me with top of tree:
% PYTHONPATH=/tmp/lldb/build/Debug/LLDB.framework/Resources/Python ; ./foo.py )
Creating a target for './a.out'
SBBreakpoint: id = 1, name = 'main', module = a.out, locations = 1
SBProcess: pid = 62855, state = stopped, threads = 1, executable = a.out
thread #1: tid
Clang just doesn't currently know where to look for the standard headers. Not
sure if this is a top level code only bug or not. I know the expression parser
can include common C headers on Darwin. Not sure if any includes work on linux.
Try importing and see how that goes?
The better way to d
Do you mean you were able to reproduce it? Because it is used to work on
trunk month ago, but since then I've switched from ubuntu 14.04 to fresh
16.04 and it no longer works for me.
2017-02-13 21:21 GMT+03:00 Greg Clayton :
> I would be probably best to just step through it and see why it is
> i
I would be probably best to just step through it and see why it is incorrectly
returning. We know it is broken. We should also add a test for this so we don't
regress again.
Greg
> On Feb 13, 2017, at 10:19 AM, Roman Popov wrote:
>
> Yes Greg, this was my expectation that it should not return
Yes Greg, this was my expectation that it should not return until stops on
break-point. But I had to downgrade sequentially from 5.0 to 4.0 to 3.9 to
make it work as expected.
Can I get some diagnostics? Any log files?
2017-02-13 20:11 GMT+03:00 Greg Clayton :
> The example code is:
>
> #!/usr/b
The example code is:
#!/usr/bin/python
import lldb
import os
def disassemble_instructions(insts):
for i in insts:
print i
# Set the path to the executable to debug
exe = "./a.out"
# Create a new debugger instance
debugger = lldb.SBDebugger.Create()
# When we step or continue, don'
Thats nice! But how to enable C++?:
(lldb) expr --top-level --
Enter expressions, then terminate with an empty line to evaluate:
1 #include
2 void HOOK() { std::cout << "in hook\n"; }
3
error: 'iostream' file not found
2017-02-13 16:46 GMT+03:00 Pavel Labath :
> Try this for size:
>
>
> $ bin
Try this for size:
$ bin/lldb /tmp/a.out
(lldb) target create "/tmp/a.out"
Current executable set to '/tmp/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 4 at a.cc:6, address = 0x00400531
(lldb) pr la
Process 22550 launched: '/tmp/a.out' (x86_64)
Process 22550 stopped
*
Yes, it would fit. I can even insert hooks manually, like:
std::function instrumentation_hook = []{ /*dear lldb script,
please insert your code here*/ }
instrumentation_hook(); // run instrumentation, by default does nothing.
Is there an easy way to compile some code in lldb and assign to
inst
Making the code persist is easy - that's sort of what expr --top-level does.
The tricky part is getting your code to execute. When you evaluate
expressions interactively, we manually modify the registers (PC being
the most important one) to point to the code you want to execute. If
you want it to
Thanks Pavel, you are correct. This was the direction I thought to
investigate, but I didnt done my homework yet.
Yes, dynamic instrumentation is what I want. Looks like both lldb and gdb
do not allow this directly.
As GDB doc says "After execution, the compiled code is removed from gdb and
any n
Every time you use the "expr" command, we compile a tiny c++ code
snippet inject it into the target process and execute it. If you type
"log enable lldb expr" you should be able to follow how exactly that
works. You can use pretty much any c++ construct in the expression
including declaring variabl
16 matches
Mail list logo
