Re: [lldb-dev] [OS X]: building lldb with cmake

[René J . V . Bertin via lldb-dev]

On Tuesday September 13 2016 11:09:11 Chris Bieneman wrote:

>> - fix finding CheckAtomic.cmake (or just install it with LLVM)
>
>CheckAtomic is installed with LLVM on trunk, and will be this way in future 
>releases.

Good, thanks for confirming that the tentative solution I adopted in my 3.9.0 
packaging was the right one.

R.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Python3 compatibility for the API

[Pavel Labath via lldb-dev]

Sounds great, I am glad to hear python3 is working on linux as well.

As for pexpect, could we just make sure our own copy of pexpect is not
on the path in this case, and have the user install a
python3-compatible version via usual means (apt-get install
python3-pexpect, in case of ubuntu).

pl

On 13 September 2016 at 21:55, Ted Woodward via lldb-dev
 wrote:
> I just built lldb on Ubuntu 12 with Python 3.5.1. I needed to set python 
> includes, python library and python executable in cmake.
>
> I found a problem with the tests - most ran fine, but I got errors with tests 
> that tried to use pexpect, like TestConvenienceVariables.py.
>   File 
> "/local/scratch/ted/8.1/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
>  line 82
> except ImportError, e:
>   ^
> SyntaxError: invalid syntax
>
> If we want to run the tests with Python3 we'll need to update pexpect.
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>
>
> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Luke 
> Drummond via lldb-dev
> Sent: Tuesday, August 30, 2016 7:01 AM
> To: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Python3 compatibility for the API
>
> Hi Zachary, Peter
>
> On 30/08/16 00:14, Zachary Turner via lldb-dev wrote:
>> Right, the existing version that is built and what you are using links
>> directly against a 2.7 libpython at compile time.  So you would
>> probably need to build LLDB from source and tweak the build system to
>> make it possible to link against your 3.x version of python.  There's
>> some build instructions on the website
>> .  I know there's a few linux
>> developers around here, so it's possible someone else would be
>> interested in making this work as well, but I don't know that it's on 
>> anyone's immediate timeline.
>
> We build lldb against python3 regularly, because - as Zachary said - this is 
> the only way to get scripting support on windows. To link against python3 on 
> Linux you *should* just need the correct headers installed, and invoke CMake 
> with the correct python path. For Ubuntu:
>
> ```
> sudo apt install python3-dev
> cmake "$PATH_TO_LLVM_SRC" -DPYTHON_EXECUTABLE:FILEPATH=$(which python3) ```
>
> *should* give you everything you need. However, you may see that cmake picks 
> up the python3 interpreter correctly, but tries to link against the python2.7 
> library.
>
> -- Found PythonInterp: /usr/bin/python3 (found version "3.5.2") [...]
> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version 
> "2.7.12")
>
> This appears to be due to a problem in LLVM's CMakeLists.txt specifying 
> support for 2.7 only. I have a patch to fix the issue awaiting review
> [here](https://reviews.llvm.org/D20825) which should fix the issue on Linux 
> when multiple pythons are installed. It may be worth applying this patch 
> locally and see how you get on.
>
> Hope that helps
>
> Best
>
> Luke
> ___
> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Help with Xcode crash on lldb_private::(anonymous namespace)::parse_builtin_type

[Greg Clayton via lldb-dev]

So any string that will be demangled by our internal demangler must start with 
"_Z". In the shared library or main application's executable mach-o file, the 
mangled names will contain an extra leading "_". We strip off this extra 
leading _ and will end up with a string of "_Z". So your string of:

Ll2ENS1H_2idINS1H_6threadEEES13_S15_S1B_EELl2ENSN_12basic_stringIcS1L_S1N_EES13_S15_S1B_EELl2EN2fl3log19logging_event_typesES13_S15_S1B_EELl2ENS2F_8internal16indent_formatterIcEEEC2ERKS2P_

is not a mangled name. You might have seen this as part of a buffer that was in 
the middle of being demangled, but you will need to step out to the initial 
invocation of the demangle function to see the original string.

Your string of:

__ZZN5boost9function4IbRNSt3__111__wrap_iterIPKcEERKS5_RNS_6spirit7contextINS_6fusion4consIRN2fl3log8internal16enable_spec_elem13compound_maskENSB_4nil_EEENSB_7vector0IvRKNS9_2qi10char_classINS9_3tag9char_codeINSR_5spaceENS9_13char_encoding5asciiEE9assign_toINSP_6detail13parser_binderINSP_4listINSP_11alternativeINSC_INSP_6actionINSP_9referenceINSP_7symbolsIcjNSP_3tstIcjEENSP_16tst_pass_throughENS_7phoenix5actorINS_5proto7exprns_10basic_exprINS1G_6tagns_3tag17bitwise_or_assignENS1G_7argsns_5list2INS1F_INS1I_INS1E_3tag4at_cENS1N_INS1I_INS1K_8terminalENS1M_4termIN4mpl_4int_ILi0ELl0EEENS1F_INS9_9attributeILi0EEELl2ENS1F_INS9_8argumentILi0EEELl2EEENSC_INS16_INSP_14literal_stringIRA5_S3_Lb1EEENS1F_INS1I_INS1K_6assignENS1N_IS21_NS1F_INS1I_IS1Q_NS1R_IiEELl0EEELl2EEENSC_INS16_INS2A_IRA4_S3_Lb1EEENS1F_INS1I_IS2E_NS1N_IS21_NS1F_INS1I_IS1Q_NS1R_IjEELl0EEELl2EEENSC_INS16_INS17_IKNSP_4ruleIS5_FjvENS1H_4exprIS1Q_NS1R_ISW_EELl0EEENS9_11unused_typeES31_NS1F_INS1I_IS2E_NS1N_INS1I_IS1P_NS1N_INS1I_IS1Q_NS1R_INS1T_ILi1ELl0EEES1Z_EELl2EEES25_EELl2EEESJ_EENSP_12literal_charINSU_8standardELb1ELb0ENS1S_5bool_ILb0EEEvT_E13stored_vtable

Needs the leading "_" stripped before you try and demangle it with 
__cxxabiv1::__cxa_demangle() or it will fail. The extra leading "_" is a mach-o 
C symbol namespace thing that doesn't belong in the name. c++filt will 
automatically strip it unless you specify -n or --no-strip-underscore.

That being said, you can just enable the logging in lldb and run it and it will 
print out what it is trying to demangle before it gets demangled and you can 
just let LLDB crash and you should be able to see the string in the STDOUT of 
the program you are debugging.

If you have any of your problem binaries that you can share, just attach them 
to the bug report and we can easily figure out what is causing the problems by 
demangling all strings inside of them.

> On Sep 13, 2016, at 8:10 AM, Sara Burke via lldb-dev 
>  wrote:
> 
> Hi Jim,
> 
> Thank you for the response!! I hadn’t subscribed to the lldb-dev mailing list 
> until now, so I did not receive your response until googling for it :p
> 
> Anyways, between when I sent my email and seeing your response, I tried very 
> similar things to what you mentioned. I built lldb from latest source and 
> replaced LLDB.framework in one of my Xcode versions with the version I built, 
> adding some of my own logging, and also turned on demangle logging (I now 
> know that I could have just used Xcode 8). 
> 
> I am seeing some interesting results. To give a bit more background on the 
> problem, let me explain it in a simplified version. Imagine we have 200 unit 
> test executables all with their own main(), cross-compiled for iOS arm64.  I 
> put these into generated Xcode projects, and we use the Xcode projects to 
> “build and run”. This allows Xcode to launch an executable as an app on an 
> iOS device. Now imagine that each executable is a unit test for an iOS static 
> library, so in this scenario we have 200 static libraries. Let’s say they are 
> all in a DAG, so library 200 depends on library 199 and library 199 depends 
> on library 198, etc. About halfway through the DAG, e.g. library 100, the 
> demangler starts to crash. In this example, every unit test executable 
> downstream of  library 100 and including library 100 are causing the 
> demangler to crash. It seems out best bet here is to find the offending 
> symbol(s) and attempt to replace the code in our codebase with something the 
> demangler can handle. 
> 
> We have run the demangle log with several different executables and the 
> demangler seems to crash on similar but slightly different symbols each time 
> (of course, the symbol the demangler appears to be crashing on isn’t 
> necessarily the offending symbol). 
> 
> Using lldb from Xcode 7.3.1, I set Xcode 7.3.0 as my target executable and 
> reproduced the crash, which allowed me to see the EXC_BAD_ACCESS in the 
> debugger (and since I have Xcode 7.3.0 using my locally built version of 
> lldb, I get to see lldb source information :p) :
> 
> Process 30313 stopped
> * thread #6: tid = 0xe0d1a, 0x0001169d19b1 L

Re: [lldb-dev] lldb type summary provider - SBProcess is invalid

[Greg Clayton via lldb-dev]

> On Sep 13, 2016, at 9:50 PM, Lei Kong via lldb-dev  
> wrote:
> 
> Thanks!
> SBValue.process works!
>  
> I have another script that I run manually to search process memory for 
> certain patterns, not a type summary provider, there is no SBValue passed to 
> my script, in such a case, how do I get current process?
>  
If this is python a command line command you are making, use the variant that 
takes an execution context:

def my_command(debugger, command, exe_ctx, result, dict):
# Always use the specified execution context to get the target, process
# thread and frame. If this command gets run from a breakpoint callback
# these will not match the debugger's selected target, the selected 
# process in the target, the selected thread in the process and the 
# selected frame in the thread.
target = exe_ctx.GetTarget()
process = exe_ctx.GetProcess()
thread = exe_ctx.GetThread()
frame = exe_ctx.GetFrame()


The execution context is explicitly specified for you.

> From: Enrico Granata
> Sent: Tuesday, September 13, 2016 10:31 AM
> To: Lei Kong
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] lldb type summary provider - SBProcess is invalid
>  
> 
>> On Sep 13, 2016, at 10:02 AM, Lei Kong via lldb-dev 
>>  wrote:
>> 
>> I wrote a lldb type summary provider for wstring with 16bit wchar on Ubuntu 
>> 16.04.
>> 
>> Things work fine if I manually do the following in lldb:
>> 
>> (lldb) script import mytypes
>> (lldb) type summary add -F mytypes.wstring_SummaryProvider 
>> "std::__1::wstring"
>> 
>> I tried to make things easier with auto-loading by adding the following to 
>> .lldbinit:
>> 
>> script import mytypes
>> type summary add -F mytypes.wstring_SummaryProvider "std::__1::wstring"
>> 
>> Then I got a failure of "SBProcess is invalid" when printing a wstring 
>> variable.
>> 
>> My type summary function has the following, which I believe is where the 
>> error is encountered:
>> 
>> content = lldb.process.ReadMemory(bufferAddr, byteCount, error)
>> 
>> Maybe this is because "process" is not assigned yet when the type summary is 
>> added during auto-loading? Or this is a bug in lldb? Does anyone know how to 
>> work around this issue?
>> 
>> 
> 
> Good hunch :-)
> Maybe we should do a better job at documenting this, but 
> http://lldb.llvm.org/python-reference.html reads
> 
> "While extremely convenient, these variables (lldb.process et alia) have a 
> couple caveats that you should be aware of. First of all, they hold the 
> values of the selected objects on entry to the embedded interpreter. They do 
> not update as you use the LLDB API's to change, for example, the currently 
> selected stack frame or thread. 
> Moreover, they are only defined and meaningful while in the interactive 
> Python interpreter. There is no guarantee on their value in any other 
> situation, hence you should not use them when defining Python formatters, 
> breakpoint scripts and commands (or any other Python extension point that 
> LLDB provides). As a rationale for such behavior, consider that lldb can run 
> in a multithreaded environment, and another thread might call the "script" 
> command, changing the value out from under you."
> 
> As part of a formatter, you get passed an SBValue. One of the things you can 
> ask of an SBValue is the process it came from, thusly:
> 
> value.GetProcess()
> 
> That's the SBProcess object you want to use
> 
>>  
>> Thanks much
>> 
>>  
>>  
>>  
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> 
> Thanks,
> - Enrico
> 📩 egranata@.com ☎️ 27683
> 
> ___
> 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] lldb type summary provider - SBProcess is invalid

[Lei Kong via lldb-dev]

Does the following qualify as "interactive usage"?  It seems using "process" 
works in myfile.func(), or I was just lucky? Thanks.
 
(lldb) script myfile.func(args)
 
> Subject: Re: [lldb-dev] lldb type summary provider - SBProcess is invalid
> From: gclay...@apple.com
> Date: Wed, 14 Sep 2016 09:33:20 -0700
> CC: egran...@apple.com; lldb-dev@lists.llvm.org
> To: leik...@msn.com
> 
> 
> > On Sep 13, 2016, at 9:50 PM, Lei Kong via lldb-dev 
> >  wrote:
> > 
> > Thanks!
> > SBValue.process works!
> >  
> > I have another script that I run manually to search process memory for 
> > certain patterns, not a type summary provider, there is no SBValue passed 
> > to my script, in such a case, how do I get current process?
> >  
> If this is python a command line command you are making, use the variant that 
> takes an execution context:
> 
> def my_command(debugger, command, exe_ctx, result, dict):
> # Always use the specified execution context to get the target, process
> # thread and frame. If this command gets run from a breakpoint callback
> # these will not match the debugger's selected target, the selected 
> # process in the target, the selected thread in the process and the 
> # selected frame in the thread.
> target = exe_ctx.GetTarget()
> process = exe_ctx.GetProcess()
> thread = exe_ctx.GetThread()
> frame = exe_ctx.GetFrame()
> 
> 
> The execution context is explicitly specified for you.
> 
> > From: Enrico Granata
> > Sent: Tuesday, September 13, 2016 10:31 AM
> > To: Lei Kong
> > Cc: lldb-dev@lists.llvm.org
> > Subject: Re: [lldb-dev] lldb type summary provider - SBProcess is invalid
> >  
> > 
> >> On Sep 13, 2016, at 10:02 AM, Lei Kong via lldb-dev 
> >>  wrote:
> >> 
> >> I wrote a lldb type summary provider for wstring with 16bit wchar on 
> >> Ubuntu 16.04.
> >> 
> >> Things work fine if I manually do the following in lldb:
> >> 
> >> (lldb) script import mytypes
> >> (lldb) type summary add -F mytypes.wstring_SummaryProvider 
> >> "std::__1::wstring"
> >> 
> >> I tried to make things easier with auto-loading by adding the following to 
> >> .lldbinit:
> >> 
> >> script import mytypes
> >> type summary add -F mytypes.wstring_SummaryProvider "std::__1::wstring"
> >> 
> >> Then I got a failure of "SBProcess is invalid" when printing a wstring 
> >> variable.
> >> 
> >> My type summary function has the following, which I believe is where the 
> >> error is encountered:
> >> 
> >> content = lldb.process.ReadMemory(bufferAddr, byteCount, error)
> >> 
> >> Maybe this is because "process" is not assigned yet when the type summary 
> >> is added during auto-loading? Or this is a bug in lldb? Does anyone know 
> >> how to work around this issue?
> >> 
> >> 
> > 
> > Good hunch :-)
> > Maybe we should do a better job at documenting this, but 
> > http://lldb.llvm.org/python-reference.html reads
> > 
> > "While extremely convenient, these variables (lldb.process et alia) have a 
> > couple caveats that you should be aware of. First of all, they hold the 
> > values of the selected objects on entry to the embedded interpreter. They 
> > do not update as you use the LLDB API's to change, for example, the 
> > currently selected stack frame or thread. 
> > Moreover, they are only defined and meaningful while in the interactive 
> > Python interpreter. There is no guarantee on their value in any other 
> > situation, hence you should not use them when defining Python formatters, 
> > breakpoint scripts and commands (or any other Python extension point that 
> > LLDB provides). As a rationale for such behavior, consider that lldb can 
> > run in a multithreaded environment, and another thread might call the 
> > "script" command, changing the value out from under you."
> > 
> > As part of a formatter, you get passed an SBValue. One of the things you 
> > can ask of an SBValue is the process it came from, thusly:
> > 
> > value.GetProcess()
> > 
> > That's the SBProcess object you want to use
> > 
> >>  
> >> Thanks much
> >> 
> >>  
> >>  
> >>  
> >> ___
> >> lldb-dev mailing list
> >> lldb-dev@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > 
> > 
> > Thanks,
> > - Enrico
> > 📩 egranata@.com ☎️ 27683
> > 
> > ___
> > 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