[lldb-dev] GetSymbolContext(lldb.eSymbolContextEverything)
Hi,
I am trying program using Lldb Python API to get an output exactly same
when I run this command "image lookup --address 0x000405a6 --verbose".
But when I print return value
of GetSymbolContext(lldb.eSymbolContextEverything), it doesnt contain the
decoding of local variables which the above commands can print out local
variables.
I have attached a simple script.py that I have developed. It is not
possible to print out local variables using the APIs or I am missing
something out?
I am looking forward to hear from you soon.
Thanks,
kmn
import lldb
import os
triple = "x86_64"
def disassemble_instructions(insts):
for i in insts:
print i
# Set the path to the executable to debug
exe = "buffer"
# Create a new debugger instance
debugger = lldb.SBDebugger.Create()
# When we step or continue, don't return from the function until the process
# stops. Otherwise we would have to handle the process events ourselves which,
while doable is
#a little tricky. We do this by setting the async mode to false.
debugger.SetAsync (False)
# Create a target from a file and arch
print "Creating a target for '%s'" % exe
target = debugger.CreateTargetWithFileAndArch (exe, lldb.LLDB_ARCH_DEFAULT)
if target:
# If the target is valid set a breakpoint at main
main_bp = target.BreakpointCreateByName
("main",target.GetExecutable().GetFilename());
#print main_bp
# Launch the process. Since we specified synchronous mode, we won't return
# from this function until we hit the breakpoint at main
process = target.LaunchSimple (None, None, os.getcwd())
# Make sure the launch went ok
if process:
# Print some simple process info
state = process.GetState ()
#print process
if state == lldb.eStateStopped:
# Get the first thread
thread = process.GetThreadAtIndex (0)
if thread:
# Print some simple thread info
#print thread
# Get the first frame
frame = thread.GetFrameAtIndex (0)
#if frame:
# Print some simple frame info
# Print some simple frame info
#print frame
#function = frame.GetFunction()
#variable = frame.GetVariables(target,True,True,True)
module = target.GetModuleAtIndex(0)
target.SetSectionLoadAddress(module.FindSection("__TEXT"),
0x1)
module = target.AddModule
("/usr/lib/system/libsystem_c.dylib", triple, None,
"/build/server/a/libsystem_c.dylib.dSYM")
target.SetSectionLoadAddress(module.FindSection("__TEXT"),
0x7fff83f32000)
module = target.AddModule
("/usr/lib/system/libsystem_dnssd.dylib", triple, None,
"/build/server/b/libsystem_dnssd.dylib.dSYM")
target.SetSectionLoadAddress(module.FindSection("__TEXT"),
0x7fff883db000)
module = target.AddModule
("/usr/lib/system/libsystem_kernel.dylib", triple, None,
"/build/server/c/libsystem_kernel.dylib.dSYM")
target.SetSectionLoadAddress(module.FindSection("__TEXT"),
0x7fff8c0dc000)
load_addr = 0x04005a6
so_addr = target.ResolveLoadAddress(load_addr)
sym_ctx =
so_addr.GetSymbolContext(lldb.eSymbolContextEverything)
print sym_ctx
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
On Jun 14, 2016, at 1:32 AM, Richard Smith via cfe-dev wrote: > I think that this is the right approach, and we happen to have a natural > forcing function here: opaque pointer types. I think we should increment the > major version number when opaque pointer types are here, as it will be a > major breaking change, and then we'll have a version 4.0. Until then, unless > something else breaking comes up, 3.10 sounds fine to me. > > We're talking about version numbers for the entire LLVM project here, which > encompasses a lot more than LLVM IR, and for many parts of which LLVM IR is > utterly irrelevant. I'm not convinced that tying version numbers to > backwards-incompatible changes to IR is reasonable any more, and it doesn't > seem hard to explicitly document the oldest version with which we are > compatible (in fact, we need to do that regardless, whether we say it's "the > same major version" or "everything since 3.0" or whatever else). > > Given that our releases are time-based rather than feature-based, I don't see > a distinct major / minor version being anything other than arbitrary, so I'd > suggest we take 4.0 as our next release, 4.1 as the first patch release on > that, 5.0 as the next release after that, and so on. I completely agree with Richard here. “Breaking of IR compatibility” was an interesting metric for older and less mature versions of LLVM. We can solve the same sort of challenge (the desire to eject old autoupgrade code) by having a sliding window of versions supported (e.g. version 4.5 supports back to version 3.6). -Chris ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
> On Jun 18, 2016, at 9:16 PM, Chris Lattner via llvm-dev > wrote: > > On Jun 14, 2016, at 1:32 AM, Richard Smith via cfe-dev > mailto:cfe-...@lists.llvm.org>> wrote: >> I think that this is the right approach, and we happen to have a natural >> forcing function here: opaque pointer types. I think we should increment the >> major version number when opaque pointer types are here, as it will be a >> major breaking change, and then we'll have a version 4.0. Until then, unless >> something else breaking comes up, 3.10 sounds fine to me. >> >> We're talking about version numbers for the entire LLVM project here, which >> encompasses a lot more than LLVM IR, and for many parts of which LLVM IR is >> utterly irrelevant. I'm not convinced that tying version numbers to >> backwards-incompatible changes to IR is reasonable any more, and it doesn't >> seem hard to explicitly document the oldest version with which we are >> compatible (in fact, we need to do that regardless, whether we say it's "the >> same major version" or "everything since 3.0" or whatever else). >> >> Given that our releases are time-based rather than feature-based, I don't >> see a distinct major / minor version being anything other than arbitrary, so >> I'd suggest we take 4.0 as our next release, 4.1 as the first patch release >> on that, 5.0 as the next release after that, and so on. > > I completely agree with Richard here. “Breaking of IR compatibility” was an > interesting metric for older and less mature versions of LLVM. We can solve > the same sort of challenge (the desire to eject old autoupgrade code) by > having a sliding window of versions supported (e.g. version 4.5 supports back > to version 3.6). Let me clarify. What I’m trying to say is that: a) LLVM has a time-based release cycle, not a schedule-based one. As such, a simple and predictable version number makes sense. b) The LLVM project as a whole is a lot bigger than LLVM IR, even given its centrality to the project in some ways. c) I think that it makes sense to keep adding 0.1 to each major release going forward well into the future. On the topic of the pointer changes proposed, I really don’t think the community is served by waiting for that. The supposition seems to be that we’d land it *without* upgrade support, but then bump the major version number to indicate this. If that’s the proposal, I think that doing such a thing would be disastrous for the LLVM community as a whole: we need to have at least some sliding window of support for older formats. -Chris ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
