Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Chris Lattner via lldb-dev]

> 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 
> > 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

[lldb-dev] GetSymbolContext(lldb.eSymbolContextEverything)

[Kamenee Arumugam via lldb-dev]

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