[lldb-dev] n00b error running lldb tests on windows?
Hi, I'm trying to run the lldb tests on Windows (fresh installs of VS2019 16.7.5, Python 3.8.5, and Swig 4.0.2). The API tests crash immediately in python initialization code: Windows fatal exception: access violation Current thread 0x693c (most recent call first): File "", line 219 in _call_with_frames_removed File "", line 1101 in create_module File "", line 556 in module_from_spec File "", line 657 in _load_unlocked File "", line 975 in _find_and_load_unlocked File "", line 991 in _find_and_load File "", line 219 in _call_with_frames_removed File "", line 1042 in _handle_fromlist File "D:\Obj\lldb\Debug\Lib\site-packages\lldb\__init__.py", line 41 in File "", line 219 in _call_with_frames_removed File "", line 783 in exec_module File "", line 671 in _load_unlocked File "", line 975 in _find_and_load_unlocked File "", line 991 in _find_and_load File "D:\Source\llvm-project\lldb\packages\Python\lldbsuite\test\dotest.py", line 898 in run_suite File "D:/Source/llvm-project/lldb\test\API\dotest.py", line 7 in Running in the debugger, I see "_PyRuntime.gc.generation0 was nullptr". I presume I have something set up incorrectly in my environment, but I haven't had much luck figuring out what. Is this by any chance an error/stack that somebody recognizes as a common/known issue? Thanks, -Joseph ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Continuing from dbgtrap on different targets
Hi,
I'm noticing an unexpected difference between targets when I hit a dbgtrap in
the debugger. Consider this simple llvm function:
define void @do_break() {
entry:
call void @llvm.debugtrap()
ret void
}
If I compile that with llc and use lldb to launch a program that calls it, on
x86_64 linux (Ubuntu 18.04), here's what I see at the stop:
Process 130404 stopped
* thread #1, name = 'doit', stop reason = signal SIGTRAP
frame #0: 0x00400541 doit`do_break at stub.ll:2:1
(lldb) disas
doit`do_break:
0x400540 <+0>: int3
-> 0x400541 <+1>: retq
(lldb) register read rip
rip = 0x00400541 doit`do_break + 1 at stub.ll:2:1
Note that rip is reported as pointing to the next instruction after the int3.
If I 'continue' from there, the program continues doing whatever was after the
debugtrap.
If I follow the same steps on aarch64 (also Ubuntu 18.04), I see this:
Process 21586 stopped
* thread #1, name = 'doit', stop reason = signal SIGTRAP
frame #0: 0x004005dc doit`do_break at stub.ll:1:1
(lldb) disas
doit`do_break:
-> 0x4005dc <+0>: brk#0x1
0x4005e0 <+4>: ret
(lldb) register read pc
pc = 0x004005dc doit`do_break at stub.ll:1:1
Note that here, pc is reported as pointing at the 'brk' instruction itself. If
I 'continue' from there, I immediately find myself stopped back at the same
point, ad infinitum.
>From what I can tell, GDB also "gets stuck" when it hits this instruction on
>aarch64 (and also doesn't on x86_64).
I'm wondering what to make of this / where's the "bug".
* Should llvm use a different lowering for dbgtrap on aarch64-linux? I
don't think so, it seems to be standard
* Should the system signal handler be reporting an incremented pc in the
context struct when it hits brk?
* And even if so, what should the workaround be for systems without such
a fix?
* Should lldb (and gdb for that matter) somehow recognize this case, and
increment pc when stopping or resuming at a brk?
* Is this just unsupported, is continuing past a debugtrap UB or otherwise
disallowed?
I'd appreciate any insights here.
Thanks,
-Joseph
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] test suite issue with Python2.7/3.5
> The 7.0 branch is not compatible with Python 3 .. The first release that is, > would be 9.0 Should some/all of the recent Python/CMake changes be ported to the 9.0 release branch? ‘git log --grep ython’ turns up r367956, r367153, r367127, r367125, r367115, r366447, and r366383, all of which happened after the fork, I’m wondering if any of them (or others) are important as part of supporting Python 3. I’ll paste the commit messages below for convenience. Thanks, -Joseph Author: Jonas Devlieghere Date: Mon Aug 5 23:54:13 2019 + [CMake] Remove check for the readline target. This was introduced when we were building a custom readline Python module on Linux [1]. Now that the readline target doesn't exist anymore, it's safe to remove this dependency. This fixes https://llvm.org/PR25136 [1] https://reviews.llvm.org/D13268 llvm-svn: 367956 Author: Jonas Devlieghere Date: Fri Jul 26 20:58:10 2019 + [CMake] Print the correct variables This didn't get updated after we decided to set PYTHON_MAJOR_VERSION and PYTHON_MINOR_VERSION in find_python_libs_windows, instead of parsing the variables ourselves. llvm-svn: 367153 Author: Jonas Devlieghere Date: Fri Jul 26 16:32:49 2019 + [CMake] Fix find_python_libs_windows Exporting PYTHON_INCLUDE_DIR to the Python scope somehow got lost in my last change. Add it back again. This should fix the Windows bot! llvm-svn: 367127 Author: Jonas Devlieghere Date: Fri Jul 26 16:15:19 2019 + [CMake] Print Python version on Windows Trying to figure out what's causing the Windows bot to fail. llvm-svn: 367125 Author: Jonas Devlieghere Date: Fri Jul 26 14:26:33 2019 + [CMake] Loosen Python version check and ignore patch version Some versions of macOS report a different patch version for the system provided interpreter and libraries. Differential revision: https://reviews.llvm.org/D65230 llvm-svn: 367115 Author: Jonas Devlieghere Date: Thu Jul 18 15:17:42 2019 + [CMake] Don't set Python_ADDITIONAL_VERSIONS Until recently, Python_ADDITIONAL_VERSIONS was used to limit LLVM's Python support to 2.7. Now that both LLVM and LLDB both support Python 3, there's no longer a need to put an arbitrary limit on this. However, instead of removing the variable, r365692 expanded the list, which has the (presumably unintentional) side-effect of expression preference for Python 3. Instead, as Michal proposed in the original code review, we should just not set the list at all, and let CMake pick whatever Python interpreter you have in your path. This patch removes the Python_ADDITIONAL_VERSIONS variable in llvm, clang and lld. I've also updated the docs with the default behavior and how to force a different Python version to be used. Differential revision: https://reviews.llvm.org/D64894 llvm-svn: 366447 Author: Adrian McCarthy Date: Wed Jul 17 22:36:26 2019 + [NFC] Clarify a Cmake status message regarding Python on LLDBConfig llvm-svn: 366383 From: lldb-dev On Behalf Of Jonas Devlieghere via lldb-dev Sent: Tuesday, July 23, 2019 10:52 AM To: Romaric Jodin Cc: LLDB Subject: Re: [lldb-dev] test suite issue with Python2.7/3.5 The 7.0 branch is not compatible with Python 3, at least not if you're not on Windows. The first release that is, would be 9.0, which is currently being qualified. This includes a bunch of compatibility fixes, and a newer version of the vendored pexpect (4.6). As you've noticed, using different versions of Python will not work either. Your only option is to use Python 2.7, both for building LLDB and for running the test suite. Making sure the 2.7 interpreter is first in your PATH should be sufficient. Alternatively, you can explicitly pass -DPYTHON_EXECUTABLE=/path/to/python27. Cheers, Jonas On Tue, Jul 23, 2019 at 7:38 AM Romaric Jodin via lldb-dev mailto:lldb-dev@lists.llvm.org>> wrote: Hi everyone, I'm trying to run the test suite on lldb and I'm having some issues with Python. I'm on branch 7.0. When I build lldb, I've got a folder "python3.5/site-packages" generated. So I believe that the build system found python3 in my environment. But when I run the testsuite (using "ninja check-lldb"), I've got this issue: Traceback (most recent call last): File "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/decorators.py", line 113, in wrapper func(*args, **kwargs) File "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/decorators.py", line 341, in wrapper return func(self, *args, **kwargs) File "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/functionalities/command_regex/TestCommandRegex.py", line 39, in test_command_regex child.expect_exact(prompt) File
[lldb-dev] Signal stack unwinding and __kernel_rt_sigreturn
Hi, I'm trying to use lldb in a project where I need to report stack traces from signal handlers, and need to do so on aarch64 Linux. Even for "synchronous" signal handling, I'm hitting a couple issues preventing this from working "out of the box": 1 - The platform signal handler trampoline function on the stack is __kernel_rt_sigreturn, not sigtramp. I'm wondering if it's ok to just add __kernel_rt_sigreturn to the list of trap handler symbol names in PlatformLinux, or if I need to include it in "UserSpecifiedTrapHandlerFunctionNames", or something else 2 - When the user handler is invoked, its return address is set to the very first byte of __kernel_rt_sigreturn, which throws off unwinding because we assume that frame must really be at a call in the preceding function. I asked about this on IRC, where Jan Kratochvil mentioned that the decrement shouldn't happen for frames with S in the eh_frame's augmentation. I've verified that __kernel_rt_sigreturn indeed has the S. I'm not sure where I'd find official documentation about that, but the DWARF Standards Committee's wiki[1] does link to Ian Lance Taylor's blog[2] which says "The character 'S' in the augmentation string means that this CIE represents a stack frame for the invocation of a signal handler. When unwinding the stack, signal stack frames are handled slightly differently: the instruction pointer is assumed to be before the next instruction to execute rather than after it." So I'm interested in encoding that knowledge in LLDB, but not sure architecturally whether it would be more appropriate to dig into the eh_frame record earlier, or to just have this be a property of symbols flagged as trap handlers, or something else. I'd very much appreciate any feedback on this. I've put up a patch[3] on Phab with a testcase that demonstrates the issue (on aarch64 linux) and an implementation of the low-churn "communicate this in the trap handler symbol list" approach. Thanks, -Joseph [1] - http://wiki.dwarfstd.org/index.php?title=Exception_Handling [2] - https://www.airs.com/blog/archives/460 [3] - https://reviews.llvm.org/D63667 ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
