[lldb-dev] [Bug 43561] New: Unwind augmentation on x86 is off by one instruction

2019-10-04 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=43561

Bug ID: 43561
   Summary: Unwind augmentation on x86 is off by one instruction
   Product: lldb
   Version: 9.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: ja...@google.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

I believe the x86 augmentation of eh_frame info from assembly is broken: it
computes the unwinding info for offset x from instruction at offset x, but
instead it should be computed from the previous instruction (here is the loop
in question:
https://github.com/llvm/llvm-project/blob/c118a03e6945805edc88732a33ff51cc4d96db09/lldb/source/Plugins/UnwindAssembly/x86/x86AssemblyInspectionEngine.cpp#L1381).
Looking back at the history of the file, this was likely introduced by the very
first revision of the file
(https://github.com/llvm/llvm-project/commit/1c9858b298d79ce82c45a2954096718b39550109#diff-375a2be066db6f34bb9a71442c9b71fcL913);
the original version handled this properly by copying the previous instruction
out before advancing the instruction pointer.

It is quite nicely visible in the glibc’s raise function, which has the
following unwinding plan (according to “image show-unwind -a $pc”):

This UnwindPlan originally sourced from eh_frame CFI plus augmentation from
assembly parsing
This UnwindPlan is sourced from the compiler: no.
This UnwindPlan is valid at all instruction locations: yes.
Address range of this UnwindPlan: [libc.so.6..text + 79344-0x000136de)
row[0]:0: CFA=rsp +8 => rip=[CFA-8]
row[1]:1: CFA=rsp+16 => rbx=[CFA-16] rip=[CFA-8]
row[2]:   28: CFA=rsp+152 => rbx=[CFA-16] rip=[CFA-8]  << Comes from
augmentation
row[3]:   35: CFA=rsp+152 => rbx=[CFA-16] rip=[CFA-8]
row[4]:  207: CFA=rsp+16 => rbx=[CFA-16] rip=[CFA-8]  << Comes from
augmentation
row[5]:  214: CFA=rsp+16 => rbx=[CFA-16] rip=[CFA-8]
row[6]:  217: CFA=rsp +8 => rbx=[CFA-16] rip=[CFA-8]
row[7]:  218: CFA=rsp +8 => rbx=[CFA-16] rip=[CFA-8]
row[8]:  224: CFA=rsp+152 => rbx=[CFA-16] rip=[CFA-8]

This is already suspicious because of the duplicate lines. Disassembling
confirms the suspicion: offsets 28 and 207 should be still on their original
unwinding rows.

0x75e94f44:  movl   $0x8, %r10d
0x75e94f4a:  xorl   %edi, %edi
0x75e94f4c:  subq   $0x88, %rsp   ;; offset 28
0x75e94f53:  leaq   -0x78(%rsp), %r9  ;; offset 35
0x75e94f58:  movq   %rax, 0x8(%rsp)
...
0x75e94ff8:  movl   $0xe, %eax
0x75e94ffd:  syscall
0x75e94fff:  addq   $0x88, %rsp   ;; offset 207
0x75e95006:  movl   %r8d, %eax;; offset 214

It is worth noting the the eh_frame unwinding info is actually correct:

This UnwindPlan originally sourced from eh_frame CFI
This UnwindPlan is sourced from the compiler: yes.
This UnwindPlan is valid at all instruction locations: no.
Address range of this UnwindPlan: [libc.so.6..text + 79344-0x000136de)
row[0]:0: CFA=rsp +8 => rip=[CFA-8]
row[1]:1: CFA=rsp+16 => rbx=[CFA-16] rip=[CFA-8]
row[2]:   35: CFA=rsp+152 => rbx=[CFA-16] rip=[CFA-8]
row[3]:  214: CFA=rsp+16 => rbx=[CFA-16] rip=[CFA-8]
row[4]:  218: CFA=rsp +8 => rbx=[CFA-16] rip=[CFA-8]
row[5]:  224: CFA=rsp+152 => rbx=[CFA-16] rip=[CFA-8]


Here is my program and the lldb session that shows the missing stack entry for
the SHOULD_BE_ON_STACK function.

--- main.cpp ---
#include 

void SHOULD_BE_ON_STACK() {
abort();
}

int main(int argc, char** argv) {
SHOULD_BE_ON_STACK();
}

$ lldb MissingStack
(lldb) target create "MissingStack"
Current executable set to 'MissingStack' (x86_64).
(lldb) r
Process 8262 launched: '/srv/game/assets/MissingStack' (x86_64)
Process 8262 stopped
* thread #1, name = 'MissingStack', stop reason = signal SIGABRT
frame #0: 0x75e94fff libc.so.6`__GI_raise(sig=6) at raise.c:51
(lldb) bt
* thread #1, name = 'MissingStack', stop reason = signal SIGABRT
  * frame #0: 0x75e94fff libc.so.6`__GI_raise(sig=6) at raise.c:51
frame #1: 0xfffe7fff
frame #2: 0x00201174 MissingStack`main(argc=1,
argv=0x7fffe5e8) at main.cpp:8
frame #3: 0x75e822e1
libc.so.6`__libc_start_main(main=(MissingStack`main at main.cpp:7), argc=1,
argv=0x7fffe5e8, init=, fini=,
rtld_fini=, stack_end=0x7fffe5d8) at libc-start.c:291
frame #4: 0x0020102a MissingStack`_start + 42

-- 
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] help, how to get a debug build on windows (python37_d.lib)

2019-10-04 Thread Alexandre Ganea via lldb-dev 
Hi Larry,



Like Pavel suggests, the option for installing Python debug binaries is here:



[cid:image001.png@01D57206.80F88AC0]


You would need to re-start the Python installer, and choose “Customize 
installation”, then you get an “Optional features” page, then a second menu 
page “Advanced Options” where you need to select “Download debug binaries”. 
This will create the python_d.exe that LLDB needs. Ensure that -DPYTHON_HOME 
properly points to the folder that you choose during installation. Also ensure 
that you have the GnuWin32 tools installed 
and visible in %PATH%, otherwise the LLDB tests won’t work.

Best,
Alex.



-Message d'origine-
De : lldb-dev  De la part de Pavel Labath via 
lldb-dev
Envoyé : September 23, 2019 7:56 AM
À : Larry D'Anna ; lldb-dev@lists.llvm.org
Objet : Re: [lldb-dev] help, how to get a debug build on windows 
(python37_d.lib)



On 22/09/2019 20:20, Larry D'Anna via lldb-dev wrote:

> Hi lldb-dev.

>

> I can’t seem to figure out how to build a debug lldb on windows.   It

> wants to link against a debug version of Python, which isn’t there.

>

> My cmake line looks like this:

>

> cmake -G Ninja `

>  "-DPYTHON_HOME=C:\Program Files (x86)\Microsoft Visual

> Studio\Shared\Python37_64" `

>  "-DLLVM_ENABLE_PROJECTS=clang;lldb;libcxx;libcxxabi;lld" `

> "-DSWIG_EXECUTABLE=C:\ProgramData\chocolatey\bin\swig.exe" `

>  "C:\Users\smoofra\llvm-project\llvm"

>

> I also made this change, to tell it to link against the release python.

>

> --- a/lldb/cmake/modules/LLDBConfig.cmake

> +++ b/lldb/cmake/modules/LLDBConfig.cmake

> @@ -227,7 +227,7 @@ function(find_python_libs_windows)

> else()

>   # Lookup for concrete python installation depending on build

> type

>   if (CMAKE_BUILD_TYPE STREQUAL Debug)

> -  set(LOOKUP_DEBUG_PYTHON TRUE)

> +  set(LOOKUP_DEBUG_PYTHON FALSE)

>   else()

> set(LOOKUP_DEBUG_PYTHON FALSE)

>   endif()

>

> But somehow at the very end, the link still fails because

> python37_d.lib isn’t there.

>

> Anybody know what I’m doing wrong?  Thank you.

>



Hi Larry,



I don't know the full details, but it is my understanding that due to how 
windows runtime libraries work (they have a separate debug and release CRT), 
all libraries in a single application need be linked against the same CRT 
flavour. IIRC, the default python installation does not come with a debug 
python, but it should be possible to install it somehow (possibly via checking 
some box in the installation dialog, but I don't remember the details).



It should also be possible to create a "fake" debug build by setting the 
CMAKE_BUILD_TYPE to Release, and enabling debug info (and disabling

optimizations) via CMAKE_CXX_FLAGS, but it's probably better to just get the 
debug python installed.



pl

___

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] [Bug 43570] New: testsuite: TestSBCommandReturnObject: object has no attribute 'dylibPath'

2019-10-04 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=43570

Bug ID: 43570
   Summary: testsuite: TestSBCommandReturnObject: object has no
attribute 'dylibPath'
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows XP
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: jan.kratoch...@redhat.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9530/steps/test/logs/stdio

AttributeError: 'TestSBCommandReturnObject' object has no attribute 'dylibPath'

Fix crash on SBCommandReturnObject & assignment
https://reviews.llvm.org/D67589
  env = {self.dylibPath: self.getLLDBLibraryEnvVal()}

I do not know how to link with liblldb on Windows so marking it as failing on
Windows.

-- 
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