[lldb-dev] [Bug 45883] Wrong Back Trace Information at O3

2020-05-12 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=45883

Jeremy Morse  changed:

   What|Removed |Added

 CC||jdevliegh...@apple.com,
   ||jeremy.morse.l...@gmail.com
   Assignee|unassignedclangbugs@nondot. |lldb-dev@lists.llvm.org
   |org |
 Status|NEW |CONFIRMED
Product|clang   |lldb
  Component|C   |All Bugs
Version|trunk   |unspecified

--- Comment #1 from Jeremy Morse  ---
Thanks for the report -- this doesn't replicate for me with gdb, but does with
an (admittedly two month old) lldb. Switching component to lldb.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 45886] New: Wrong variable value change during debugging at Og

2020-05-12 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=45886

Bug ID: 45886
   Summary: Wrong variable value change during debugging at Og
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: massare...@diag.uniroma1.it
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

The variable b inside function a changes value unexpectedly at line 3.

$ cat a.c
void a(b) {
  printf("%X\n");
}

int main() {
  a(0);
}

$ lldb -v
lldb version 11.0.0
  clang revision c25b20c0f6c13d68dbc2e185764082d61ae4a132
  llvm revision c25b20c0f6c13d68dbc2e185764082d61ae4a132

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/tmp/gcc_build --disable-multilib
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200511 (experimental) (GCC) 

$ gcc -Og -g -o opt_2 a.c

$ lldb opt_2

(lldb) b main
Breakpoint 1: where = opt_2`main + 4 at a.c:6:3, address = 0x0040050e
(lldb) r
Process 313 launched: 'opt_2' (x86_64)
Process 313 stopped
* thread #1, name = 'opt_2', stop reason = breakpoint 1.1
frame #0: 0x0040050e opt_2`main at a.c:6:3
   3}
   4
   5int main() {
-> 6  a(0);
   7}
(lldb) s
Process 313 stopped
* thread #1, name = 'opt_2', stop reason = step in
frame #0: 0x004004f2 opt_2`a(b=0) at a.c:1:11
-> 1void a(b) {
   2  printf("%X\n");
   3}
   4
   5int main() {
   6  a(0);
   7}
(lldb) s
Process 313 stopped
* thread #1, name = 'opt_2', stop reason = step in
frame #0: 0x004004f6 opt_2`a(b=0) at a.c:2:3
   1void a(b) {
-> 2  printf("%X\n");
   3}
   4
   5int main() {
   6  a(0);
   7}
(lldb) s
E5B8
Process 313 stopped
* thread #1, name = 'opt_2', stop reason = step in
frame #0: 0x00400505 opt_2`a(b=1) at a.c:3:1
   1void a(b) {
   2  printf("%X\n");
-> 3}
   4
   5int main() {
   6  a(0);
   7}
(lldb) p b
(int) $0 = 1

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB_PYTHON_HOME

2020-05-12 Thread Adrian McCarthy via lldb-dev 
Setting extra Python3 strategy variables in the Cmake call didn't solve the
problem.  They may have been necessary, but they weren't sufficient.

In the end, I installed Python 3.8.2, and pointed everything at that.  For
reasons I haven't discovered, Cmake seems to choose that one over the
incomplete Python 3.7 distribution that's bundled with Visual Studio.  (The
obvious guess is that it's a higher version number, but the Cmake
documentation denies that.)

"Listen, strange women lying in ponds *Cmake* distributing swords *selecting
Python installations* is no basis for a system of government *cross-platform
build configuration.*"

On Mon, May 11, 2020 at 4:34 PM Adrian McCarthy  wrote:

> Ug.  After a rebase, this problem has again resurfaced for me.
>
> * PATH has only C:\Python36
> * cmake version 3.15.19101501-MSVC_2
> * cmake -GNinja -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON
> -DCMAKE_BUILD_TYPE=Debug -DLLDB_TEST_DEBUG_TEST_CRASHES=1 
> -DPYTHON_HOME=C:\Python36
> -DLLDB_PYTHON_HOME=C:\Python36 -DPython3_ROOT_DIR=C:\Python36
> -DLLDB_TEST_COMPILER=D:\src\llvm\build\ninja_dbg\bin\clang.exe
> ..\..\llvm-project\llvm -DLLVM_ENABLE_ZLIB=OFF
> -DLLVM_ENABLE_PROJECTS="clang;lld;lldb;debuginfo-tests"
>
> Yet when linking LLDB, it goes looking at the Python 3.7 installation that
> comes with Visual Studio.  That wouldn't be much of a problem unless you're
> trying to build debug, which I am.  The VS version, doesn't come with debug
> versions of the interpreter libraries, so the link fails:
>
> [1/7] Linking CXX shared library bin\liblldb.dll
> FAILED: bin/liblldb.dll lib/liblldb.lib
> cmd.exe /C "cd . && "C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe"
> -E vs_link_dll --intdir=tools\lldb\source\API\CMakeFiles\liblldb.dir
> --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100183~1.0\x64\rc.exe
> --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100183~1.0\x64\mt.exe --manifests  --
> C:\PROGRA~2\MICROS~1\2019\PROFES~1\VC\Tools\MSVC\1424~1.283\bin\Hostx64\x64\link.exe
> /nologo @CMakeFiles\liblldb.rsp  /out:bin\liblldb.dll
> /implib:lib\liblldb.lib /pdb:bin\liblldb.pdb /dll /version:11.0
> /machine:x64 /debug /INCREMENTAL   && cd ."
> LINK Pass 1: command
> "C:\PROGRA~2\MICROS~1\2019\PROFES~1\VC\Tools\MSVC\1424~1.283\bin\Hostx64\x64\link.exe
> /nologo @CMakeFiles\liblldb.rsp /out:bin\liblldb.dll
> /implib:lib\liblldb.lib /pdb:bin\liblldb.pdb /dll /version:11.0
> /machine:x64 /debug /INCREMENTAL /MANIFEST
> /MANIFESTFILE:tools\lldb\source\API\CMakeFiles\liblldb.dir/intermediate.manifest
> tools\lldb\source\API\CMakeFiles\liblldb.dir/manifest.res" failed (exit
> code 1104) with the following output:
> LINK : fatal error LNK1104: cannot open file 'python37_d.lib'
> ninja: build stopped: subcommand failed.
>
> It looks like Cmake has added several more hints for finding Python
> .  I'm
> trying now with -DPython3_FIND_REGISTRY=LAST.
>
> I miss hermetic builds.
>
> On Thu, Feb 27, 2020 at 11:33 AM Adrian McCarthy 
> wrote:
>
>> >  This was all fixed in CMake 3.12.
>>
>> For some definitions of "all fixed." ;-)
>>
>> It seems weird to me that FindPython3 found the VS-distributed Python,
>> which isn't mentioned anywhere in the environment block, and that it chose
>> that one over the Python 3 installation that was in the path and that
>> included the interpreters and all of the corresponding libraries.
>>
>> >  With FindPython{2,3} you know you'll have a matching interpreter and
>> library.
>>
>> The build failure was that the Python distributed in VS does not have a
>> debug version of the library (python37_d.lib), so you don't actually get a
>> matching interpreter and library for debug builds.
>>
>> It's also not clear whether LLVM was consistently using the Python found
>> the old way.  My generated build.ninja file seemed to be using both
>> versions inconsistently to run lit tests and the like.
>>
>> Anyway, thanks for the explanations.  I've LGTMed your patch, which
>> should eliminate future surprises when something else smuggles yet another
>> version of Python onto a machine.
>>
>> On Thu, Feb 27, 2020 at 11:14 AM Jonas Devlieghere 
>> wrote:
>>
>>> So to make my previous explanation more concrete:
>>>
>>> On Thu, Feb 27, 2020 at 11:05 AM Jonas Devlieghere <
>>> jo...@devlieghere.com> wrote:
>>>


 On Thu, Feb 27, 2020 at 10:53 AM Adrian McCarthy 
 wrote:

> Thanks for the info.  Setting Python3_ROOT_DIR solves the problem.
>
> Looking at the cmake output from before setting Python3_ROOT_DIR,
> cmake looks for Python twice and finds it at the two different locations.
>
> Early on:
>
> -- Found PythonInterp: C:/Python36/python.exe (found version "3.6.8")
>

>>> ^ This is using the "old" (CMake < 3.12) way of finding the Python
>>> interpreter.
>>>
>>>

> Which looks good (modulo the incorrect slash direction).  But later:
>

[lldb-dev] [Bug 45892] New: LLDB fails to calculate backtrace from libc functions on arm

2020-05-12 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=45892

Bug ID: 45892
   Summary: LLDB fails to calculate backtrace from libc functions
on arm
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: omair.jav...@linaro.org
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

TestThreadAPI.py step_out_of_malloc_into_function_b fails on arm-linux. 

Executable runs to breakpoint on malloc and fails to calculate backtrace from
there. This can also be reproduced on various other libc functions.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 45893] New: Assert StackFrame Recognizer fails on arm-linux 32bit

2020-05-12 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=45893

Bug ID: 45893
   Summary: Assert StackFrame Recognizer fails on arm-linux 32bit
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: omair.jav...@linaro.org
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

lldb/test/Shell/Recognizer/assert.test fails on arm-linux (32 bit
arm/gnu-linux)

Command Output (stderr):
--
+ : 'RUN: at line 2'
+ /home/omair.javaid/work/lldb/build/armhf/bin/clang
--target=specify-a-target-or-use-a-_host-substitution
--target=armv8l-unknown-linux-gnueabihf -pthread
-fmodules-cache-path=/home/omair.javaid/work/lldb/build/armhf/lldb-test-build.noindex/module-cache-clang/lldb-shell
-g -O0
/home/omair.javaid/work/lldb/llvm-project/lldb/test/Shell/Recognizer/Inputs/assert.c
-o
/home/omair.javaid/work/lldb/build/armhf/tools/lldb/test/Recognizer/Output/assert.test.tmp.out
clang-11: warning: argument unused during compilation:
'-fmodules-cache-path=/home/omair.javaid/work/lldb/build/armhf/lldb-test-build.noindex/module-cache-clang/lldb-shell'
[-Wunused-command-line-argument]
+ : 'RUN: at line 3'
+ /home/omair.javaid/work/lldb/build/armhf/bin/lldb --no-lldbinit -S
/home/omair.javaid/work/lldb/build/armhf/tools/lldb/test/Shell/lit-lldb-init -b
-s
/home/omair.javaid/work/lldb/llvm-project/lldb/test/Shell/Recognizer/assert.test
/home/omair.javaid/work/lldb/build/armhf/tools/lldb/test/Recognizer/Output/assert.test.tmp.out
+ /home/omair.javaid/work/lldb/build/armhf/bin/FileCheck
/home/omair.javaid/work/lldb/llvm-project/lldb/test/Shell/Recognizer/assert.test
/home/omair.javaid/work/lldb/llvm-project/lldb/test/Shell/Recognizer/assert.test:5:10:
error: CHECK: expected string not found in input
# CHECK: thread #{{.*}}stop reason = hit program assert
 ^
:1:1: note: scanning from here
(lldb) command source -s 0
'/home/omair.javaid/work/lldb/build/armhf/tools/lldb/test/Shell/lit-lldb-init'
^
:16:34: note: possible intended match here
* thread #1, name = 'assert.test.tmp', stop reason = signal SIGABRT

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 41706] LLDB is broken on arm-linux-gnu-eabihf

2020-05-12 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=41706

Omair Javaid  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 45894] New: LLDB LoadImageUsingPaths fails on 32bit arm linux platform

2020-05-12 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=45894

Bug ID: 45894
   Summary: LLDB LoadImageUsingPaths fails on 32bit arm linux
platform
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: omair.jav...@linaro.org
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

TestLoadUsingPaths.py fails on 32bit arm linux platform.

==
FAIL: test_load_using_paths (TestLoadUsingPaths.LoadUsingPathsTestCase)
   Test that we can load a module by providing a set of search paths.
--
Traceback (most recent call last):
  File
"/home/omair.javaid/work/lldb/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py",
line 140, in wrapper
func(*args, **kwargs)
  File
"/home/omair.javaid/work/lldb/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py",
line 462, in wrapper
func(*args, **kwargs)
  File
"/home/omair.javaid/work/lldb/llvm-project/lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py",
line 73, in test_load_using_paths
self.assertNotEqual(token, lldb.LLDB_INVALID_IMAGE_TOKEN, "Got a valid
token")
AssertionError: 4294967295L == 4294967295L : Got a valid token
Config=arm-/home/omair.javaid/work/lldb/build/armhf/bin/clang-11
--

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev