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 <
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
Re: [lldb-dev] What's the latest version of gdbserver supported by LLDB
We don't tend to look at the GDB built gdbserver at all. Feel free to submit patches to fix anything or add support for anything that gdbserver doesn't have. We are open to changes, but they are not a priority since we have our own lldb-server and debugserver on MacOSX. Greg Clayton > On Jun 15, 2016, at 7:20 AM, Ravitheja Addepally via lldb-dev > wrote: > > Hello, > Debugging with gdbserver is supported by LLDB, but does it support > all the features that are present in the latest version of gdbserver ? If not > till what version of gdbserver does it support ? and are there any future > plans to support the latest gdbserver ? > > Best Regards, > A Ravi Theja > ___ > 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] Symbolicate user processes when kernel debugging
The right way to do this is to say "I want a GDB server port for user space process 123". The python would then start up a socket that can be connected to that can vend the information about the user space process directly through a dedicated GDB server port. Memory reads would translate the memory asked for through the GDB server port into a physical address and do the read for you as if the memory read came from user space process 123. I know someone had this code working here at Apple, but I am not sure if it made it into the macros. You might check around for such a thing as it might already be in there. Then you can also read memory and read registers just as you would with a core file. Then you can skip all of the manual symbolication stuff as the process will set itself up correctly if the GDB server is responding to all the right questions. So check around and make sure this isn't already checked into the code. Greg Clayton > On Jun 16, 2016, at 1:38 AM, John Otter via lldb-dev > wrote: > > I'm using lldb to debug the OS X kernel, and it works great. > I would like to have more flexibility in analysing user programs while > debugging the kernel itself, > and specifically symbolicate the code of the user programs. > > For example I often use the command showthreaduserstack defined here > http://opensource.apple.com//source/xnu/xnu-2422.1.72/tools/lldbmacros/userspace.py > to take > a look at the user stack of a process running in kernel mode that just > scripts the process of > obtaining the thread saved state, but the output unfortunately isn't > symbolicated. > > Is there a way to add symbols for a user process (programs and shared libs?) > I looked into the target modules add command, but when I try to add a > copy of the executable > it just says that the file I pick doesn't exist (even though it clearly > exist). > Also I'm not entirely sure how that would work since the user space > addressing space changes > for every process, even if I manually set the loading address. > Would that work only for that specific process and execution? > > Regards, > John > ___ > 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)
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
Re: [lldb-dev] [Openmp-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
> On Jun 19, 2016, at 12:25 AM, Hal Finkel wrote: > > 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 > To be clear, that's not at all what I was saying. The plan has always been to > have upgrade support. My thought was that once the pointer changes land, it > will mean major changes in how many frontends and IR transformations use the > API. A lot of out-of-tree frontends and passes support multiple versions of > LLVM, and use ifdefs to work around relevant API changes. For the most part, > this works reasonably, and the changes necessary between versions are not > often large (perhaps especially because we have time-based releases). I > suspect, however, that the amount of code changes necessary to adapt for the > pointer changes will be much larger, and so calling that a new major version > seems fitting. API breakage isn’t a concern, every release of LLVM breaks APIs. I don’t see a reason to “delay” LLVM 4.0. -Chris___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
