[PATCH] D144999: [Clang][MC][MachO]Only emits compact-unwind format for "canonical" personality symbols. For the rest, use DWARFs.

[Jason Molenda via Phabricator via cfe-commits]

jasonmolenda added a comment.

Michael and I looked into this.  This simple c++ file is resulting in eh_frame 
unwind info on aarch64 darwin instead of compact unwind info.  The eh_frame 
instructions don't describe the epilogue, so lldb is stopping on the final RET 
instruction after it has adjusted $sp back to its original value and the unwind 
now fails to work in the debugger.  That's always the problem with 
eh_frame/debug_frame from the debugger's point of view - it's only guaranteed 
to describe the unwind state at throwable locations.  gdb lives exclusively off 
of eh_frame/debug_frame so in practice gcc/clang (at least on intel) describe 
both the prologue and the epilogue for the debugger's benefit.  But that's not 
what this eh_frame includes on aarch64 darwin, and it breaks the debugger 
because it's trusting the eh_frame to be accurate at every instruction point.

The emission of eh_frame on aarch64 darwin instead of compact unwind, for this 
simple codegen, is a bug and cannot remain in the tree unfixed.  It will 
increase binary size and reduce throw performance.  It also happens to cause 
lldb regressions like this because we've never lived off of eh_frame as our 
primary unwind format on this platform, but that's a separate issue and I'm not 
going to dig in to finding a way to detect this & ignore the eh_frame on this 
target.

Looking at the failing test case that Michael has been debugging, none of these 
methods have a personality, and yet we're getting eh_frame instead of compact 
unwind.  That's the bug.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144999/new/

https://reviews.llvm.org/D144999

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

[PATCH] D128465: [llvm] add zstd to `llvm::compression` namespace

[Jason Molenda via Phabricator via cfe-commits]

jasonmolenda added a comment.

In D128465#3653216 , @ckissane wrote:

> In D128465#3653051 , @jasonmolenda 
> wrote:
>
>> In D128465#3652525 , @ckissane 
>> wrote:
>>
>>> In D128465#3651025 , @aemerson 
>>> wrote:
>>>
 I just reverted this in 6e6be5f9504d 
  
 because it seems to have broken macOS builds:

   llvm/lib/Support/Compression.cpp:24:10: fatal error: 'zstd.h' file not 
 found
   #include 
^~~~
>>>
>>> @aemerson Could you provide the output of your cmake command?
>>> (I can't easily reproduce because I don't have a mac on hand)
>>
>> FWIW I hit this last night on my mac desktop - it looked like I had zstd 
>> installed by homebrew (as a dependency on something I installed), and cmake 
>> was able to find it in /opt/homebrew (somehow) but when Compression.cpp was 
>> built, nothing had added -I/opt/homebrew/include so the header wasn't found. 
>>  I hacked the FindZSTD.cmake to not find it, to finish what I was working on 
>> before bedtime.  This might not be related to what @aemerson saw though.
>
> @jasonmolenda Thank you for the info, I believe it is similar, could you try: 
> https://reviews.llvm.org/D129786 for me?

I applied the patch from https://reviews.llvm.org/D129786 on a clean checkout, 
` cmake ../llvm -G Ninja -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_ASSERTIONS=1 
-DLLVM_ENABLE_PROJECTS='llvm;lldb;clang' 
'-DLLVM_ENABLE_RUNTIMES=libcxx;libcxxabi' -DLLDB_ENABLE_PYTHON=1` (my normal 
cmake line) and got

  -- Found ZSTD: /opt/homebrew/lib/libzstd.dylib  
  -- Looking for ZSTD_compress
  -- Looking for ZSTD_compress - found
  
  [...]
  
  FAILED: lib/Support/CMakeFiles/LLVMSupport.dir/Compression.cpp.o 
  
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
 -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -I/Users/jason/k/llvm/llvm-project/build/lib/Support 
-I/Users/jason/k/llvm/llvm-project/llvm/lib/Support 
-I/Users/jason/k/llvm/llvm-project/build/include 
-I/Users/jason/k/llvm/llvm-project/llvm/include -fPIC 
-fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion 
-Wmisleading-indentation -fdiagnostics-color  -g -arch arm64 -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk
 -std=c++14  -fno-exceptions -fno-rtti -MD -MT 
lib/Support/CMakeFiles/LLVMSupport.dir/Compression.cpp.o -MF 
lib/Support/CMakeFiles/LLVMSupport.dir/Compression.cpp.o.d -o 
lib/Support/CMakeFiles/LLVMSupport.dir/Compression.cpp.o -c 
/Users/jason/k/llvm/llvm-project/llvm/lib/Support/Compression.cpp
  /Users/jason/k/llvm/llvm-project/llvm/lib/Support/Compression.cpp:24:10: 
fatal error: 'zstd.h' file not found
  #include 
   ^~~~
  1 error generated.
  
  % file /opt/homebrew/lib/libzstd.dylib 
  /opt/homebrew/lib/libzstd.dylib: Mach-O 64-bit dynamically linked shared 
library arm64
  % head -2 /opt/homebrew/include/zstd.h 
  /*
   * Copyright (c) Yann Collet, Facebook, Inc.
  %
  
  % grep -i zstd CMakeCache.txt 
  //Use zstd for compression/decompression if available. Can be ON,
  LLVM_ENABLE_ZSTD:STRING=ON
  ZSTD_INCLUDE_DIR:PATH=/opt/homebrew/include
  ZSTD_LIBRARY:FILEPATH=/opt/homebrew/lib/libzstd.dylib
  //Details about finding ZSTD
  
FIND_PACKAGE_MESSAGE_DETAILS_ZSTD:INTERNAL=[/opt/homebrew/lib/libzstd.dylib][/opt/homebrew/include][v()]
  //Have symbol ZSTD_compress
  HAVE_ZSTD:INTERNAL=1
  //ADVANCED property for variable: ZSTD_INCLUDE_DIR
  ZSTD_INCLUDE_DIR-ADVANCED:INTERNAL=1
  //ADVANCED property for variable: ZSTD_LIBRARY
  ZSTD_LIBRARY-ADVANCED:INTERNAL=1


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128465/new/

https://reviews.llvm.org/D128465

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

[PATCH] D128465: [llvm] add zstd to `llvm::compression` namespace

[Jason Molenda via Phabricator via cfe-commits]

jasonmolenda added a comment.

In D128465#3652525 , @ckissane wrote:

> In D128465#3651025 , @aemerson 
> wrote:
>
>> I just reverted this in 6e6be5f9504d 
>>  
>> because it seems to have broken macOS builds:
>>
>>   llvm/lib/Support/Compression.cpp:24:10: fatal error: 'zstd.h' file not 
>> found
>>   #include 
>>^~~~
>
> @aemerson Could you provide the output of your cmake command?
> (I can't easily reproduce because I don't have a mac on hand)

FWIW I hit this last night on my mac desktop - it looked like I had zstd 
installed by homebrew (as a dependency on something I installed), and cmake was 
able to find it in /opt/homebrew (somehow) but when Compression.cpp was built, 
nothing had added -I/opt/homebrew/include so the header wasn't found.  I hacked 
the FindZSTD.cmake to not find it, to finish what I was working on before 
bedtime.  This might not be related to what @aemerson saw though.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128465/new/

https://reviews.llvm.org/D128465

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

[PATCH] D36347: Add new script to launch lldb and set breakpoints for diagnostics all diagnostics seen.

[Jason Molenda via Phabricator via cfe-commits]

jasonmolenda added a comment.

Sorry for missing this back in August.

I think it'd be clearer to import your python once in the startup, like

-o "script import $module" \

Multiple imports are a no-op IIUC so it's harmless to re-import the module 
every time the breakpoint is hit (I'm guessing it's only hit once, for that 
matter), but I think it's clearer to have this on its own line.

For what it's worth, if you use breakpoint command add -F python-function, your 
function is passed in the frame as well as the SBBreakpointLocation.  See 'help 
breakpoint add' for more information about this; I used this in a breakpoint 
python command I wrote a while back,

def handle_pthread_create_return(frame, bp_loc, dict):

  global pthreads_being_created
  
  thread_index_id = frame.GetThread().GetIndexID()

[...]

it might be a good idea to name the breakpoint you're adding and then you can 
delete it explicitly, in case the user is doing something unexpected with 
breakpoints.  e.g.

% ~/k/svn/lldb/build/Debug/lldb /tmp/a.out
(lldb) target create "/tmp/a.out"
Current executable set to '/tmp/a.out' (x86_64).
(lldb) br s -n main -N worker
Breakpoint 1: where = a.out`main, address = 0x00010ec0
(lldb) br del worker
1 breakpoints deleted; 0 breakpoint locations disabled.
(lldb) br li
No breakpoints currently set.
(lldb)


https://reviews.llvm.org/D36347



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits