[Lldb-commits] [PATCH] D48782: LLDB Test Suite: Provide an Option to run all tests with Dwarf Package Format (DWP).

[Puyan Lotfi via Phabricator via lldb-commits]

plotfi added a comment.

In https://reviews.llvm.org/D48782#1148498, @alexshap wrote:

> @labath
>
> > I am not denying that there is value in running the dotest suite in all of 
> > these modes. In fact, I think that (the fact that we can use the same tests 
> > to exercise a lot of different scenarios) is one of the strengths ?>of our 
> > test suite. However, I don't believe all of these modes should be inflicted 
> > onto everyone running lldb tests or be our first and only line of defense 
> > against regressions.
>
> for what it's worth - not sure how much you care about my opinion, but i 
> think it's an important point but it doesn't actually contradict or prevent 
> your second point regarding adding regression tests using lldb-test, however 
> i think those should be added over time (sadly no tests were added when the 
> support for .dwp was implemented / introduced) (not in this patch).
>  I think that the approach of this patch is still useful, this mode can be 
> off by default, but if smb needs to run all the tests with dwps - it's easy 
> to do by passing or setting a variable (for example).


yes, thats the near term solution.

In https://reviews.llvm.org/D48782#1148288, @aprantl wrote:

> Is your plan to add dwp as another dimension in the test matrix (an equal 
> citizen of DWARF, dSYM, DWO) or something that would be on or off for an 
> entire run of the suite, or something only exercised by few specialized 
> testcases?


another dimension, off by default

In https://reviews.llvm.org/D48782#1148929, @JDevlieghere wrote:

> In https://reviews.llvm.org/D48782#1148376, @labath wrote:
>
> > Then, for the integration test part, I propose to come up with a more 
> > generic way to specify the kind of debug info to generate. I don't have 
> > this fully thought out yet, but I have been thinking of something that 
> > could wrap the compiler invocation with some user specified script. Then we 
> > could use the same mechanism to run DWP and DWZ with any kind of crazy 
> > compiler flags we think of (which is definitely useful when bringing up 
> > support for a new kind of debug info format). If someone has a particular 
> > interest in a specific combo, he can set up a bot which runs tests in this 
> > mode (details about who would be responsible for fixing failures TBD)
>
>
> I really like that idea. It sounds similar to the EXPENSIVE_CHECKS we have 
> for LLVM. Personally I'd love to have an overnight job that runs the test 
> suite with DWARF5 for example.


Oh, I see. Have some generic option for debug format to make this problem 
simpler every time it arises.




Comment at: packages/Python/lldbsuite/test/make/Makefile.rules:238
 
+ifneq (,$(wildcard $(LLVM_DWP)))
+  MAKE_DWP=YES

alexshap wrote:
> aprantl wrote:
> > Is the fact this this is *llvm-*dwp critical, or are llvm-dwp and GNU dwp 
> > interchangeable? In the latter case, I'd prefer to drop the LLVM part from 
> > the variable.
> llvm-dwp and dwp should both work
Ah good. I will do that. 


https://reviews.llvm.org/D48782



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

[Lldb-commits] [PATCH] D48782: LLDB Test Suite: Provide an Option to run all tests with Dwarf Package Format (DWP).

[Puyan Lotfi via Phabricator via lldb-commits]

plotfi updated this revision to Diff 155452.

https://reviews.llvm.org/D48782

Files:
  packages/Python/lldbsuite/test/make/Makefile.rules


Index: packages/Python/lldbsuite/test/make/Makefile.rules
===
--- packages/Python/lldbsuite/test/make/Makefile.rules
+++ packages/Python/lldbsuite/test/make/Makefile.rules
@@ -235,6 +235,22 @@
CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) 
$(ARCH_CFLAGS) $(CFLAGS_EXTRAS)
 endif
 
+ifneq (,$(wildcard $(DWP)))
+  MAKE_DWP=YES
+  VALID_DWP_BIN=YES
+endif
+
+ifeq "$(MAKE_DWP)" "YES"
+  MAKE_DWO=YES
+  ifndef DWP
+$(error dwp not found, please set DWP.)
+  endif
+  ifneq "$(VALID_DWP_BIN)" "YES"
+$(error Invalid dwp, please set DWP to a path that exists.)
+  endif
+endif
+
+
 ifeq "$(MAKE_DWO)" "YES"
CFLAGS += -gsplit-dwarf
 endif
@@ -508,6 +524,10 @@
 else
 $(EXE) : $(OBJECTS) $(ARCHIVE_NAME)
$(LD) $(OBJECTS) $(LDFLAGS) $(ARCHIVE_NAME) -o "$(EXE)"
+ifeq "$(MAKE_DWP)" "YES"
+   $(DWP) -e "$(EXE)" -o "$(EXE).dwp"
+   rm -f $(OBJECTS:.o=.dwo)
+endif
 endif
 
 #--


Index: packages/Python/lldbsuite/test/make/Makefile.rules
===
--- packages/Python/lldbsuite/test/make/Makefile.rules
+++ packages/Python/lldbsuite/test/make/Makefile.rules
@@ -235,6 +235,22 @@
CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS)
 endif
 
+ifneq (,$(wildcard $(DWP)))
+  MAKE_DWP=YES
+  VALID_DWP_BIN=YES
+endif
+
+ifeq "$(MAKE_DWP)" "YES"
+  MAKE_DWO=YES
+  ifndef DWP
+$(error dwp not found, please set DWP.)
+  endif
+  ifneq "$(VALID_DWP_BIN)" "YES"
+$(error Invalid dwp, please set DWP to a path that exists.)
+  endif
+endif
+
+
 ifeq "$(MAKE_DWO)" "YES"
CFLAGS += -gsplit-dwarf
 endif
@@ -508,6 +524,10 @@
 else
 $(EXE) : $(OBJECTS) $(ARCHIVE_NAME)
$(LD) $(OBJECTS) $(LDFLAGS) $(ARCHIVE_NAME) -o "$(EXE)"
+ifeq "$(MAKE_DWP)" "YES"
+   $(DWP) -e "$(EXE)" -o "$(EXE).dwp"
+   rm -f $(OBJECTS:.o=.dwo)
+endif
 endif
 
 #--
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D48782: LLDB Test Suite: Provide an Option to run all tests with Dwarf Package Format (DWP).

[Puyan Lotfi via Phabricator via lldb-commits]

plotfi added a comment.



> What's the medium-to-long term solution?

Havn't fully fleshed that out yet.




Comment at: packages/Python/lldbsuite/test/make/Makefile.rules:520
 $(EXE) : $(OBJECTS) $(ARCHIVE_NAME) $(DYLIB_FILENAME)
$(LD) $(OBJECTS) $(ARCHIVE_NAME) -L. -l$(DYLIB_NAME) $(LDFLAGS) -o 
"$(EXE)"
 else

jankratochvil wrote:
> Shouldn't be $(LLVM_DWP) even here? DWZ mode has its command even here.
Ah, I can add it. I wasn't sure if dwp was something that works with dylibs or 
not. Thought there was something like dsym for those. 



Comment at: packages/Python/lldbsuite/test/make/Makefile.rules:546
$(OBJCOPY) --strip-debug --add-gnu-debuglink="$(DSYM)" "$(EXE)" "$(EXE)"
 endif
 endif

jankratochvil wrote:
> Shouldn't be $(LLVM_DWP) even here? DWZ mode has its command even here.
I'm not sure about this one. 


https://reviews.llvm.org/D48782



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

[Lldb-commits] [PATCH] D62034: compiler-rt/lib/builtins: s/#include /#include /g to match proper case.

[Puyan Lotfi via Phabricator via lldb-commits]

plotfi added a comment.
Herald added a subscriber: dexonsmith.

In D62034#1506102 , @mstorsjo wrote:

> Yes, MinGW headers are all lowercase.
>
> And the Windows SDK, where the file is spelled with a capital W, isn't 
> self-consistent (some headers include others with a different capitalization 
> than the files actually are stored with), so to use the official Windows SDK 
> on a case sensitive file system, you need some sort of case fixup anyway. (Or 
> did that change very recently?) And in that case, making it all lowercase is 
> the simplest, which also happens to match the MinGW headers.


We can't control the case mismatches in the Windows SDK but we can control them 
in LLVM. Why should we consistently use the wrong case? The difference between 
LLVM and the Windows SDK using the wrong case is, that we can maintain a vfs 
overlay file for the Windows SDK only and be fairly certain that it wont change 
that frequently.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62034



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

[Lldb-commits] [PATCH] D62034: compiler-rt/lib/builtins: s/#include /#include /g to match proper case.

[Puyan Lotfi via Phabricator via lldb-commits]

plotfi updated this revision to Diff 200067.
plotfi added a comment.
Herald added subscribers: openmp-commits, libcxx-commits, lldb-commits, 
cfe-commits, lebedev.ri, kadircet, arphaman, jkorous, christof, hiraditya, 
mgorny, ki.stfu, kubamracek.
Herald added a reviewer: jfb.
Herald added a reviewer: lebedev.ri.
Herald added projects: clang, LLDB, libc++, OpenMP.

adding all windows.h's in all of monorepo


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62034

Files:
  clang-tools-extra/clangd/Threading.cpp
  clang/lib/Driver/ToolChains/MSVC.cpp
  clang/tools/libclang/CIndexer.cpp
  compiler-rt/lib/BlocksRuntime/runtime.c
  compiler-rt/lib/asan/asan_win.cc
  compiler-rt/lib/asan/asan_win_dynamic_runtime_thunk.cc
  compiler-rt/lib/builtins/emutls.c
  compiler-rt/lib/builtins/enable_execute_stack.c
  compiler-rt/lib/fuzzer/FuzzerIOWindows.cpp
  compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp
  compiler-rt/lib/interception/interception_win.cc
  compiler-rt/lib/interception/tests/interception_win_test.cc
  compiler-rt/lib/profile/CMakeLists.txt
  compiler-rt/lib/profile/GCDAProfiling.c
  compiler-rt/lib/profile/InstrProfilingPort.h
  compiler-rt/lib/profile/InstrProfilingUtil.c
  compiler-rt/lib/profile/WindowsMMap.c
  compiler-rt/lib/sanitizer_common/sanitizer_dbghelp.h
  compiler-rt/lib/sanitizer_common/sanitizer_unwind_win.cc
  compiler-rt/lib/sanitizer_common/sanitizer_win.cc
  compiler-rt/lib/sanitizer_common/tests/sanitizer_libc_test.cc
  compiler-rt/lib/stats/stats_client.cc
  compiler-rt/test/asan/TestCases/Windows/aligned_mallocs.cc
  compiler-rt/test/asan/TestCases/Windows/beginthreadex.cc
  compiler-rt/test/asan/TestCases/Windows/bind_io_completion_callback.cc
  compiler-rt/test/asan/TestCases/Windows/bitfield.cc
  compiler-rt/test/asan/TestCases/Windows/bitfield_uaf.cc
  compiler-rt/test/asan/TestCases/Windows/crash_read_write.cc
  compiler-rt/test/asan/TestCases/Windows/dll_control_c.cc
  compiler-rt/test/asan/TestCases/Windows/dll_heap_allocation.cc
  compiler-rt/test/asan/TestCases/Windows/dll_host.cc
  
compiler-rt/test/asan/TestCases/Windows/dll_report_globals_symbolization_at_startup.cc
  compiler-rt/test/asan/TestCases/Windows/dll_seh.cc
  compiler-rt/test/asan/TestCases/Windows/dll_thread_stack_array_left_oob.cc
  compiler-rt/test/asan/TestCases/Windows/global_const_string.cc
  compiler-rt/test/asan/TestCases/Windows/global_const_string_oob.cc
  compiler-rt/test/asan/TestCases/Windows/operator_array_new_right_oob.cc
  compiler-rt/test/asan/TestCases/Windows/operator_array_new_uaf.cc
  compiler-rt/test/asan/TestCases/Windows/operator_delete_wrong_argument.cc
  compiler-rt/test/asan/TestCases/Windows/operator_new_left_oob.cc
  compiler-rt/test/asan/TestCases/Windows/operator_new_right_oob.cc
  compiler-rt/test/asan/TestCases/Windows/operator_new_uaf.cc
  compiler-rt/test/asan/TestCases/Windows/queue_user_work_item.cc
  compiler-rt/test/asan/TestCases/Windows/queue_user_work_item_report.cc
  compiler-rt/test/asan/TestCases/Windows/recalloc_sanity.cc
  compiler-rt/test/asan/TestCases/Windows/report_after_syminitialize.cc
  compiler-rt/test/asan/TestCases/Windows/report_globals_reload_dll.cc
  compiler-rt/test/asan/TestCases/Windows/report_globals_vs_freelibrary.cc
  compiler-rt/test/asan/TestCases/Windows/seh.cc
  compiler-rt/test/asan/TestCases/Windows/thread_simple.cc
  compiler-rt/test/asan/TestCases/Windows/thread_stack_array_left_oob.cc
  compiler-rt/test/asan/TestCases/Windows/thread_stack_array_right_oob.cc
  compiler-rt/test/asan/TestCases/Windows/thread_stack_reuse.cc
  compiler-rt/test/asan/TestCases/Windows/thread_stress.cc
  compiler-rt/test/asan/TestCases/Windows/thread_suspended.cc
  compiler-rt/test/asan/TestCases/Windows/tls_init.cc
  compiler-rt/test/asan/TestCases/Windows/user-exception.cc
  compiler-rt/test/asan/TestCases/Windows/windows_h.cc
  compiler-rt/test/asan/TestCases/exitcode.cc
  compiler-rt/test/asan/TestCases/ill.cc
  compiler-rt/test/builtins/Unit/clear_cache_test.c
  libcxx/src/chrono.cpp
  libcxx/src/support/win32/thread_win32.cpp
  libcxx/src/thread.cpp
  libcxx/utils/google-benchmark/src/colorprint.cc
  libcxx/utils/google-benchmark/src/sleep.cc
  libcxx/utils/google-benchmark/src/sysinfo.cc
  libcxx/utils/google-benchmark/src/timers.cc
  libcxxabi/src/cxa_personality.cpp
  libunwind/include/unwind.h
  libunwind/src/AddressSpace.hpp
  libunwind/src/RWMutex.hpp
  libunwind/src/UnwindCursor.hpp
  lldb/include/lldb/Host/windows/windows.h
  lldb/packages/Python/lldbsuite/test/python_api/hello_world/main.c
  lldb/packages/Python/lldbsuite/test/python_api/signals/main.cpp
  lldb/packages/Python/lldbsuite/test/tools/lldb-server/main.cpp
  lldb/source/Utility/Status.cpp
  lldb/tools/lldb-mi/MICmnStreamStdin.cpp
  lldb/tools/lldb-mi/MIUtilDebug.cpp
  lldb/tools/lldb-vscode/IOStream.h
  lldb/tools/lldb-vscode/lldb-vscode.cpp
  llgo/third_party/gofrontend/libffi/src/dlmalloc.c
  llgo/third_

[Lldb-commits] [PATCH] D62034: compiler-rt/lib/builtins: s/#include /#include /g to match proper case.

[Puyan Lotfi via Phabricator via lldb-commits]

plotfi added a comment.

In D62034#1506879 , @mclow.lists wrote:

> I have no objection to this; but I'm not really confident that this won't 
> break more than it solves.


Actually, I think the existing VFS overlay would fix this without any changes. 
So I will likely pull this patch back.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62034



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