In D132611#3747396, @kcc wrote:

not arguing for or against, but I wonder how many output parsers will break.

test update

In D128998#3721563, @MaskRay wrote:

About __unw_clean_step:

libunwind/src/libunwind_ext.h provides a bunch of API which are not implemented by https://github.com/libunwind/libunwind .
Before we settle on an API there, it's worth raising an issue on https://github.com/libunwind/libunwind and giving them some time for the API design.

address comments

add comment

In D103562#3702962, @smd wrote:

Hi folks,

I've been working on support hwasan for risc-v and I believe I've found an issue with the existing lit tests this commit causes.
Tests stack-{oob,uar,uas}.c check for correct backtrace being printed. From the code and comments the idea is to not to print any hwasan related frames(see the code and comments below).

void HandleTagMismatch(AccessInfo ai, uptr pc, uptr frame, void *uc,                                
                       uptr *registers_frame) {                                                     
  InternalMmapVector<BufferedStackTrace> stack_buffer(1);                                           
  BufferedStackTrace *stack = stack_buffer.data();                                                  
  stack->Reset();                                                                                   
  stack->Unwind(pc, frame, uc, common_flags()->fast_unwind_on_fatal);                               
                                                                                                    
  // The second stack frame contains the failure __hwasan_check function, as                        
  // we have a stack frame for the registers saved in __hwasan_tag_mismatch that                    
  // we wish to ignore. This (currently) only occurs on AArch64, as x64                      
  // implementations use SIGTRAP to implement the failure, and thus do not go                       
  // through the stack saver.                                                                       
  if (registers_frame && stack->trace && stack->size > 0) {                                         
    stack->trace++;                                                                              
    stack->size--;                                                                               
  }

Before this commit the return address and frame pointer to were taken directly from hwasan_tag_mismatch4, while after the commit those addresses are calculated after another function being called from hwasan_tag_mismatch4 (the HwasanTagMismatch one).
So, if I understand it correctly, now it looks like 2 stack frames must be ignored(for hwasan_tag_mismatch4 and HwasanTagMismatch) to get a proper backtrace.
What do you think?

Thanks

In addition to the test described in the message, I ran the libunwind test suites on FVP with SANITIZE_TARGET=memtag-stack and they still pass.

In D130956#3697869, @craig.topper wrote:

I'll revert, I'll have to do a fixup for a dependent patch that I committed after this.

This seems related to an error we see on our sanitizer bots: https://lab.llvm.org/buildbot/#/builders/37/builds/15446/steps/33/logs/stdio

This CL seems to have an MSAN violation: https://lab.llvm.org/buildbot/#/builders/74/builds/12529/steps/11/logs/stdio

In rG9028966a717239cf586d6c4f606965d444176dc4#1111707, @abrachet wrote:

In rG9028966a717239cf586d6c4f606965d444176dc4#1111704, @fmayer wrote:

This broke the sanitizer buildbot: https://lab.llvm.org/buildbot/#/builders/168/builds/7879/steps/11/logs/stdio

Should be fixed at HEAD by https://github.com/llvm/llvm-project/commit/71f2d5c2d195256f27f293aefdc1d4f6c117065d

This broke the sanitizer buildbot: https://lab.llvm.org/buildbot/#/builders/168/builds/7879/steps/11/logs/stdio

I think this broke the sanitizer-windows buildbot: https://lab.llvm.org/buildbot/#/builders/127/builds/33583/steps/4/logs/stdio

Looks good! Please add "[NFC]" to the commit message to indicate this change is non-functional.

FWIW this is not really NFC, I found this as the culprit in bisecting the Android LLVM toolchain build, causing the following error:

In D127917#3602467, @eugenis wrote:

Could you add a test?

add test

In D127913#3600203, @myhsu wrote:

Mostly LG. Just curious if the analysis results would be invalidated between GetDT/GetPDT calls (in the original code)?

address comments.

Gentle ping.

add requires aarch64

require aarch64-registered-target

Tests broke on windows.

Tests broke on windows.

Consistency

remove comments

address comment

address comment

rebase

test

address comments

address comments

add another test

In D127148#3562065, @MaskRay wrote:

llvm/lib/DebugInfo/DWARF/DWARFDebugFrame.cpp code can be tested with llvm-objdump/llvm-dwarfdump but should have a test in test/DebugInfo.

lld doesn't use llvm/lib/DebugInfo/DWARF/DWARFDebugFrame.cpp code. It's inappropriate to rely on lld/test/ELF to provide the test coverage.

You should move llvm/lib/DebugInfo/DWARF/DWARFDebugFrame.cpp into another patch with a test/DebugInfo patch.

remove dwarf test

remove DWARF parser

Accidentally duplicated this.

test no REQUIRES

test

In D127007#3562088, @MaskRay wrote:

It may be better to move the DebugInfo change from the lld patch into this patch.