Re: [lldb-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
Ø 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). How easy/hard is it to identify the minor release associated with a particular auto-upgrade feature? My impression is that they aren't identified that way in the source, that it would be an archeological dig each time to figure out which bits could be removed. --paulr From: Chris Lattner [mailto:clatt...@apple.com] Sent: Saturday, June 18, 2016 9:16 PM To: Richard Smith Cc: Hal Finkel; llvm-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB Dev; r jordans; cfe-dev; Robinson, Paul Subject: Re: [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 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). -Chris ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] GitHub anyone?
For what it is worth, I fully support *any* change that moves us away from having our own infrastructure. We should really stop hosting our own code repositories, databases and mailing lists. For that, I support the proposal to move to github, but would also support moving to another hosting service. Cheers, Rafael On 10 June 2016 at 14:25, Tim Northover via cfe-dev wrote: > On 2 June 2016 at 08:48, Renato Golin via lldb-dev > wrote: >> Of all those issues, Windows tooling is a minor problem that shouldn't >> impact decision that much and sub-modules need a lot of ironing out to >> be considered good enough. My *personal* take away is that sub-modules >> (or an alternative server side solution) is the only strong technical >> issue we need to solve before we decide. > > I think Takumi's repository and script covers the real uses > (bisection, principally) as well as we need and probably better than > SVN. I suppose we might extend it to put an auto-incrementing revision > number in the commit message too, but that's trivial. > > I think the responses in the thread have been heavily in favour > (including after AAron's mention in LLVM weekly), so we should either > get a more rigorous survey going as Tanya suggested (if we think it's > useful) or get started on the actual move. > > I'm not really convinced that a survey would reach enough of a wider > audience to affect our actions here, though I think the results would > be very interesting anyway in the longer term (particularly on > preferred workflows). > >> How does a move look like? >> >> If we decide to move, the proposed schedule is something like this: >> >> STEP #1 : Pre Move >> >> [...] >> 1. Register an official GitHub project with the LLVM foundation. > > Chandler already did that: https://github.com/llvm. So we're one step > in already! > > Tim. > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] GetSymbolContext(lldb.eSymbolContextEverything)
Hi Greg,
Thanks for your reply. I did try the method you mention above but
variable.GetLocation() only provide me the memory address of the variable.
What exactly I am looking for was the register offset that stores variable
i here. Example, I am looking for method able to output the one highlighted
in yellow:
Variable: id = {0x00a2}, name = "i", type= "int", location =
DW_OP_fbreg(-564), decl = ivm_demo.c:6
Basically, I am working on a binary instrumentation research tool, that
will inject code to check changes on selected variable. Therefore, using
register offset, I am able to inject check for instruction using this
register with this offset.
Please let me know if you have any better method to grab register offset
for particular variable.
Thanks,
Kamenee
On Mon, Jun 20, 2016 at 7:15 PM, Greg Clayton wrote:
> The variables are available through the frame in your symbol context. You
> have a line of code commented out in your script:
>
> #variable = frame.GetVariables(target,True,True,True)
>
> Change it to:
>
> get_arguments = True # Get argument variables
> get_locals = True # Get local variables
> get_statics = True # Get globals and static variables
> get_in_scope_only = True # only get variables that are in scope
> use_dynamic = lldb.eDynamicDontRunTarget # Get dynamic types for variables
> variables = frame.GetVariables (get_arguments, get_locals, get_statics,
> get_in_scope_only, use_dynamic)
> print variables
>
> This output will look different from the output in "image lookup --address
> 0x... --verbose" because we have an actual frame here so we can dump the
> variable value itself because we have a stack frame that allows us to have
> variable values. If you want the location of the variable you can also
> print that in a for loop using "variables" from above:
>
> for variable in variables:
> print str(variable)
> print "Location = %s" % (variable.GetLocation())
>
>
> Each "variable" object is a lldb.SBValue type. There are many API calls on
> these that you can call manually depending on what you want. Let me know if
> you have any questions.
>
> Greg Clayton
>
>
>
>
> > On Jun 17, 2016, at 11:34 AM, Kamenee Arumugam via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > 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
> > ___
> > 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] GetSymbolContext(lldb.eSymbolContextEverything)
We currently don't expose this information through the API, though we could.
You could add a new method to SBValue:
namespace lldb
{
class SBValue
{
SBData GetDWARFLocation();
}
};
This could return the DWARF location as a SBData object. Then you could consume
the data by parsing the DWARF DW_OP enumerations. Otherwise you can parse the
textual output of the "image lookup -va 0x123" command:
result = lldb.SBCommandReturnObject()
ci = debugger.GetCommandInterpreter()
ci.HandleCommand("image lookup -va %#x" % (frame.GetPC()), result, False)
# Now all output from the above command is in "result"
output = result.GetOutput()
# Parse "output" for variable locations
> On Jun 21, 2016, at 9:07 AM, Kamenee Arumugam wrote:
>
> Hi Greg,
>
> Thanks for your reply. I did try the method you mention above but
> variable.GetLocation() only provide me the memory address of the variable.
> What exactly I am looking for was the register offset that stores variable i
> here. Example, I am looking for method able to output the one highlighted in
> yellow:
>
> Variable: id = {0x00a2}, name = "i", type= "int", location =
> DW_OP_fbreg(-564), decl = ivm_demo.c:6
>
>
> Basically, I am working on a binary instrumentation research tool, that will
> inject code to check changes on selected variable. Therefore, using register
> offset, I am able to inject check for instruction using this register with
> this offset.
> Please let me know if you have any better method to grab register offset for
> particular variable.
>
> Thanks,
> Kamenee
>
> On Mon, Jun 20, 2016 at 7:15 PM, Greg Clayton wrote:
> The variables are available through the frame in your symbol context. You
> have a line of code commented out in your script:
>
> #variable = frame.GetVariables(target,True,True,True)
>
> Change it to:
>
> get_arguments = True # Get argument variables
> get_locals = True # Get local variables
> get_statics = True # Get globals and static variables
> get_in_scope_only = True # only get variables that are in scope
> use_dynamic = lldb.eDynamicDontRunTarget # Get dynamic types for variables
> variables = frame.GetVariables (get_arguments, get_locals, get_statics,
> get_in_scope_only, use_dynamic)
> print variables
>
> This output will look different from the output in "image lookup --address
> 0x... --verbose" because we have an actual frame here so we can dump the
> variable value itself because we have a stack frame that allows us to have
> variable values. If you want the location of the variable you can also print
> that in a for loop using "variables" from above:
>
> for variable in variables:
> print str(variable)
> print "Location = %s" % (variable.GetLocation())
>
>
> Each "variable" object is a lldb.SBValue type. There are many API calls on
> these that you can call manually depending on what you want. Let me know if
> you have any questions.
>
> Greg Clayton
>
>
>
>
> > On Jun 17, 2016, at 11:34 AM, Kamenee Arumugam via lldb-dev
> > wrote:
> >
> > 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
> > ___
> > 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] [Bug 28253] New: lldb-mi Regression with LLDB_DISABLE_PYTHON=1
https://llvm.org/bugs/show_bug.cgi?id=28253
Bug ID: 28253
Summary: lldb-mi Regression with LLDB_DISABLE_PYTHON=1
Product: lldb
Version: 3.8
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: pierson@microsoft.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
When running self-built lldb-mi(3.8.1) with LLDB_DISABLE_PYTHON=1, on execution
time, I'm getting:
MI: Error: Driver. LLDB Debugger.
MI: Error: Driver Manager. Driver 'Machine Interface Driver Version: 1.0.0.9'
(ID:'MIDriver') initialise failed. Driver. LLDB Debugger.
Ilia K helped me determine that it is due to r251082 change.
The suggested workaround is:
1. ignore MI_add_summary's errors by returning TRUE:
```
Index: tools/lldb-mi/MICmnLLDBDebugger.cpp
===
--- tools/lldb-mi/MICmnLLDBDebugger.cpp(revision 273137)
+++ tools/lldb-mi/MICmnLLDBDebugger.cpp(working copy)
@@ -58,7 +58,7 @@
uint32_t options, bool regex = false)
{
#if defined(LLDB_DISABLE_PYTHON)
-return false;
+return true;
#else
lldb::SBTypeSummary summary = lldb::SBTypeSummary::CreateWithCallback(cb,
options);
return summary.IsValid() ?
category.AddTypeSummary(lldb::SBTypeNameSpecifier(typeName, regex), summary) :
false;
```
In this case, wide chars will not be expanded unlike simple chars:
```
(gdb) -var-create - * cp
^done,name="var7",numchild="1",value="0x00400cb4
\"\\t\\\"hello\\\"\\n\"",type="const char *",thread-id="1",has_more="0"
(gdb) -var-create - * u16p
^done,name="var9",numchild="1",value="0x00400d64",type="const char16_t
*",thread-id="1",has_more="0"
```
2. or you can try to revert r251082
I did #1 but would probably like wide chars to be expanded (which it does not
with the workaround).
--
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Error when using lldb-mi built with LLDB_DISABLE_PYTHON
Hi Ilia,
Thanks for the reply. I did #1 for our workaround for the time being and opened
https://llvm.org/bugs/show_bug.cgi?id=28253.
Thanks!
-Pierson
From: Ilia K [mailto:ki.s...@gmail.com]
Sent: Monday, June 20, 2016 1:45 AM
To: Pierson Lee (PIE)
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Error when using lldb-mi built with LLDB_DISABLE_PYTHON
Hi!
Unfortunately, this is a regression introduced in r251082. From that moment
lldb-mi requires LLDB_DISABLE_PYTHON=0 for showing wide chars: char16/char32
types.
If you cannot enable python support, I suggest you to:
1. ignore MI_add_summary's errors by returning TRUE:
```
Index: tools/lldb-mi/MICmnLLDBDebugger.cpp
===
--- tools/lldb-mi/MICmnLLDBDebugger.cpp(revision 273137)
+++ tools/lldb-mi/MICmnLLDBDebugger.cpp (working copy)
@@ -58,7 +58,7 @@
uint32_t options, bool regex = false)
{
#if defined(LLDB_DISABLE_PYTHON)
-return false;
+return true;
#else
lldb::SBTypeSummary summary = lldb::SBTypeSummary::CreateWithCallback(cb,
options);
return summary.IsValid() ?
category.AddTypeSummary(lldb::SBTypeNameSpecifier(typeName, regex), summary) :
false;
```
In this case, wide chars will not be expanded unlike simple chars:
```
(gdb) -var-create - * cp
^done,name="var7",numchild="1",value="0x00400cb4
\"\\t\\\"hello\\\"\\n\"",type="const char
*",thread-id="1",has_more="0"
(gdb) -var-create - * u16p
^done,name="var9",numchild="1",value="0x00400d64",type="const char16_t
*",thread-id="1",has_more="0"
```
2. or you can try to revert r251082.
Please fill a bug report on
llvm.org/bugs
and tell me if you have other issues.
On Sat, Jun 18, 2016 at 3:35 AM, Pierson Lee (PIE) via lldb-dev
mailto:lldb-dev@lists.llvm.org>> wrote:
Hi,
I’ve built lldb on tag release_38 (3.8.1) with the flag LLDB_DISABLE_PYTHON=1
and I’m getting the below error when running lldb-mi:
MI: Error: Driver. LLDB Debugger.
MI: Error: Driver Manager. Driver 'Machine Interface Driver Version: 1.0.0.9'
(ID:'MIDriver') initialise failed. Driver. LLDB Debugger.
Am I missing something?
Thanks
Pierson
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
--
- Ilia
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
