Re: [lldb-dev] [cfe-dev] 8.0.1-rc4 release has been tagged.

[Hans Wennborg via lldb-dev]

Sorry for the late reply. Back from vacation now :-)

On Thu, Jul 11, 2019 at 5:25 AM Tom Stellard via cfe-dev
 wrote:
> I've tagged the 8.0.1-rc4 release, please begin testing.  This will 
> (hopefully)
> be the last release candidate.  If all goes well, I will tag the final release
> next Wednesday.

Windows looks good.

$ sha256sum *8.0.1-rc4*
0dc6b8750e5c4a7eb375bd3c00c93e52dbf165ca491f6a90329c0589ae64bd8f
LLVM-8.0.1-rc4-win32.exe
d9a60ffe5cbb5a130e26deaec10e390a68bf157c575afc7f40d8c55b8ec1c520
LLVM-8.0.1-rc4-win64.exe

Thanks,
Hans


build_llvm_801-rc4._bat_
Description: Binary data
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Type Validation and Dexter

[Greg Clayton via lldb-dev]

> On Jul 15, 2019, at 5:56 AM, Tom Weaver via lldb-dev 
>  wrote:
> 
> Dear LLDB dev community
> 
> I'm currently working on an open source project called DExTer. DExTer is used 
> to help validate and check the debugging experience a user might have when 
> debugging a program. The LLVM community is interested in using DExTer as a 
> means to run DebugInfo-Integration tests. A needed feature of DExTer is to be 
> able to validate arbitrary type information during program execution.
> 
> We're currently trying to implement support for correct type testing in 
> DExTer. We'd like test writers to be able to validate arbitrary types exists 
> at some point during program execution. We'd like to be able to validate the 
> types of PODs, class types, template types amongst others.
> 
> Dexter supports multiple debuggers, of which LLDB is one and as we're pushing 
> for use with LLVM DebugInfo-Integration tests, I've been working on 
> implementing this functionality with LLDB first.
> 
> However, I can't find a way to validate the type of a template parameter. 
> According to the "GDB to LLDB command map" article :
> 
>   https://lldb.llvm.org/use/map.html 
> 
> LLDB's equivalent to GDB's "ptype" feature is "image lookup --type ". 
> When using GDB's ptype command it's possible to query the type of a template 
> parameter, see example below:
> 
> 1 template
> 2 T foo(const T & bar) {
> 3   return bar + bar;
> 4 }
> 5
> 6 int main() {
> 7   return foo(5);
> 8 }
> 
> I'd like to be able to break on line 3 in the above example and find out what 
> the type of "T" is in the instantiated template function foo.
> 
> With GDB's ptype function, I'm able to type "ptype T" and get back the type 
> name "int". This doesn't seem to be possible with LLDBs "image lookup --type" 
> command.
> 
> With LLDB, breaking on line 3 and executing the following command "image 
> lookup --type T" I get back an empty string. I can however, lookup the type 
> "int" and get back a result.
> 
> Similarly, when using the LLDB python API, I can't call 
> "lldb.SBTarget.FindFirstType('T')" and get back anything other than an empty 
> SBType object. Again, I can look up the type "int".
> 
> So, I'd like to ask, is LLDB capable of validating template parameter types? 
> 
> If there isn't support for arbitrary type validating of template parameters 
> in LLDB, then are there plans for future work to support it? We'd really like 
> to have this functionality for our DebugInfo-Integration test suite.

The better way to get this information in LLDB would be to get the type for the 
variable "bar" and then work from there.

In python this would can easily be done with the python API:

>>> var = frame.FindVariable('bar')
>>> print var
(const int &) bar = 0x7ffeefbff768 (&bar = 5)
>>> var_type = var.GetType()
>>> print var_type
const int &
>>> var_type = var_type.GetDereferencedType()
>>> print var_type
const int
>>> var_type = var_type.GetUnqualifiedType()
>>> print var_type
int

To do this all in one step you can do:
>>> var_type = var.GetType().GetDereferencedType().GetUnqualifiedType()
>>> print var_type
int

Will this help? 
> 
> Kindest regards,
> Tom Weaver.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[lldb-dev] How to debug "Python memory allocator called without holding the GIL" during LLDB tests?

[Adrian McCarthy via lldb-dev]

Several LLDB tests on Windows are now failing for me like this:

Fatal Python error: Python memory allocator called without holding the GIL

Current thread 0x081c (most recent call first):
  File "D:\src\llvm\build\mono\lib\site-packages\lldb\__init__.py", line
14461 in GetNumChildren
  File
"D:\src\llvm\mono\llvm-project\lldb\packages\Python\lldbsuite\test\python_api\formatters\TestFormattersSBAPI.py",
line 478 in test_force_synth_off
  File
"D:\src\llvm\mono\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py",
line 1738 in test_method
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\case.py",
line 413 in runMethod
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\case.py",
line 383 in run
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\case.py",
line 458 in __call__
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\suite.py",
line 117 in _wrapped_run
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\suite.py",
line 115 in _wrapped_run
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\suite.py",
line 85 in run
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\suite.py",
line 66 in __call__
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\runner.py",
line 165 in run
  File
"D:\src\llvm\mono\llvm-project\lldb\packages\Python\lldbsuite\test\dotest.py",
line 1443 in run_suite
  File "D:/src/llvm/mono/llvm-project/lldb/test/dotest.py", line 7 in


I'm not sure how to go about debugging the problem.  Note that the crash is
in SWIG-generated code called by standard SBAPI tests that used to work
just fine.  (There are actually a few different tests that trigger the
problem, but TestFormattersSBAPI.py is typically the first and sometimes
only one on any given run.)

I tried bisecting, but it turns out the problem coincided with an
environmental change rather than a patch.

My environment changed to accommodate rL366243, which tries to ensure that
the version of the Python interpreter detected by CMake matches the version
of the Python libraries found by LLDBConfig, which has special logic on
Windows so that the user can override the version of Python that LLDB uses.

That version check failed because CMake detected Python 2.7 rather than
Python 3.6, which I had specified with PYTHON_HOME.  This apparently has
happened for a very long time, but it had never caused a problem until the
version check was added.  As far as I can tell, on Windows, LLDB uses the
Python from PYTHON_HOME and/or the PATH and completely ignores the one
CMake finds.

The only way I could satisfy the version check was to eliminate Python 2.7
from my machine so that CMake had no choice but to detect 3.6.

There was additional confusion, as the Python 2.7 uninstaller also removed
make from my machine!  (Weird, right?)

Ever since I restored make, running LLDB tests results in the error and
stack reported at the top of this message.  (Annoyingly, this sometimes
causes a popup dialog that must be manually dismissed.  Once you've
dismissed it, the tests are usually hung.  Canceling out of the tests
leaves zombie Python processes that hold locks on various files, so there
are additional manual steps to clean up.)

To summarize, the environmental changes are:

1.  Only one version of Python remains on the machine:

Python 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 24 2018, 00:16:47) [MSC v.1916 64
bit (AMD64)] on win32

2.  Whatever version of make I was using vanished and was replaced by the
one that comes with GnuWin32:

GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i386-pc-mingw32

Clues appreciated.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev