Re: [lldb-dev] Questions about the LLDB testsuite and improving its reliability

[Adrian Prantl via lldb-dev]

> On Jan 18, 2018, at 5:07 AM, Pavel Labath  wrote:
> 
> Looks like I missed a party. :)
> 
> I'll try to give my thoughts on some of the things that were said here:
> 
>> make -C
> I don't think make -C does what you think it does. "make -C foo" is
> basically equivalent to "cd foo && make", which is what we are doing
> now already. Of course, you can make this work, but you would have to
> pass an extra OUTDIR=... argument to make and then modify the
> Makefiles to reference $(OUTDIR) for its outputs:
> $(OUTDIR)/a.out: main.cc
>  $(CC) -o $(OUTDIR)/a.out main.cc ...
> 
> The standard way of doing an out-of-tree build with make is to have
> the Makefile in the build-directory and to set the magic VPATH
> variable in the Makefile (or as a part of make invocation). VPATH
> alters make's search path, so when searching for a dependency foo and
> the foo is not present in the current (build) directory, it will go
> searching for it in the VPATH (source) directory. You still need to be
> careful about paths in the command line (generally this means using
> make variables like $@ and $< instead of bare file names), but our
> makefiles are generally pretty good at this already. We even have a
> couple of makefiles using VPATH already (see TestConcurrentEvents) --
> Todd added this to speed up the build by spreading out tests over
> different folders while sharing sources (the serial execution
> problem).
> 
> I still fully support being able to build the tests out of tree, I
> just think it may be a bit more involved than you realise.

I uploaded my first attempt of implementing something along these lines to 
https://reviews.llvm.org/D42281 . Feedback of all kinds is very welcome!

-- adrian


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

Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 1 tagged

[Dimitry Andric via lldb-dev]

On 17 Jan 2018, at 18:53, Hans Wennborg via Release-testers 
 wrote:
> 
> Start your engines; 6.0.0-rc1 was just tagged.
> 
> I know there are still open blockers and it's early in the process in
> a way, but I'd like to find out where we are. Please run the test
> script, let me know the results, and upload binaries.

Another problem I'm running into is that check-all fails with a Python 
ValueError.  The last part of the log is (this is just after most stuff has 
been built, and lit is starting up):

[100%] Running all regression tests
llvm-lit: /home/dim/llvm-6.0.0/rc1/llvm.src/projects/libunwind/test/lit.cfg:58: 
note: Using configuration variant: libunwind
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:307:
 note: inferred use_system_cxx_lib as: None
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:313:
 note: inferred with_availability as: False
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:345:
 note: inferred use_clang_verify as: True
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:355:
 note: enabling thread-safety annotations
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:535:
 note: inferred language dialect as: c++2a
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:436:
 note: inferred long_tests as: True
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:156:
 note: Using compiler: 
/home/dim/llvm-6.0.0/rc1/Phase2/Release/llvmCore-6.0.0-rc1.install/usr/local/bin/clang++
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:157:
 note: Using flags: ['-v', '-D_LIBCPP_DISABLE_AVAILABILITY', 
'-ftemplate-depth=270']
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:162:
 note: Using compile flags: ['-Werror=thread-safety', '-DLIBUNWIND_NO_TIMER', 
'-fno-exceptions', '-DLIBUNWIND_HAS_NO_EXCEPTIONS', '-funwind-tables', 
'-std=c++2a', '-I/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libunwind/include', 
'-Itest/support']
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:164:
 note: Using warnings: ['-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER', '-Wall', 
'-Wextra', '-Werror', '-Wuser-defined-warnings', '-Wshadow', 
'-Wno-unused-command-line-argument', '-Wno-attributes', 
'-Wno-pessimizing-move', '-Wno-c++11-extensions', '-Wno-user-defined-literals', 
'-Wno-noexcept-type', '-Wno-aligned-allocation-unavailable', '-Wsign-compare', 
'-Wunused-variable', '-Wunused-parameter', '-Wunreachable-code', 
'-Wno-conversion', '-Wno-unused-local-typedef', '-Wno-#warnings']
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:165:
 note: Using link flags: 
['-L/home/dim/llvm-6.0.0/rc1/Phase3/Release/llvmCore-6.0.0-rc1.obj/./lib', 
'-Wl,-rpath,/home/dim/llvm-6.0.0/rc1/Phase3/Release/llvmCore-6.0.0-rc1.obj/./lib',
 '-nodefaultlibs', '-lc++', '-lc++abi', '-lc', '-lm', '-lpthread', '-lgcc_s', 
'-lcxxrt']
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:168:
 note: Using available_features: ['libc++', 'verify-support', 'clang-6', 
'modules-support', 'locale.en_US.UTF-8', 'diagnose-if-support', 'long_tests', 
'fdelayed-template-parsing', '-faligned-allocation', 'c++2a', 
'locale.fr_CA.ISO8859-1', 'clang', 'locale.fr_FR.UTF-8', 
'libcxxabi-no-exceptions', 'locale.ru_RU.UTF-8', 'fsized-deallocation', 
'locale.zh_CN.UTF-8', 'freebsd10', 'fcoroutines-ts', 'locale.cs_CZ.ISO8859-2', 
'clang-6.0', 'thread-safety']
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:173:
 note: Adding environment variables: {}
llvm-lit: /home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/test/lit.cfg:45: 
note: Using configuration variant: libcxx
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:307:
 note: inferred use_system_cxx_lib as: None
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:313:
 note: inferred with_availability as: False
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:345:
 note: inferred use_clang_verify as: True
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:355:
 note: enabling thread-safety annotations
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:535:
 note: inferred language dialect as: c++2a
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:436:
 note: inferred long_tests as: True
llvm-lit: 
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/libcxx/utils/libcxx/test/config.py:156:
 note: Using compiler: 

Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 1 tagged

[Michał Górny via lldb-dev]

W dniu śro, 17.01.2018 o godzinie 18∶53 +0100, użytkownik Hans Wennborg
via Release-testers napisał:
> Dear testers,
> 
> Start your engines; 6.0.0-rc1 was just tagged.
> 
> I know there are still open blockers and it's early in the process in
> a way, but I'd like to find out where we are. Please run the test
> script, let me know the results, and upload binaries.
> 

Well, initial results for Gentoo are not good. Looks like there are
a number of regression for stand-alone builds of everything, and LLDB
is still completely broken with mysterious (not a regression):

  error: process launch failed: 'A' packet returned an error: -1

Regressions:

- lld: tests broken with stand-alone builds (reported [1], patch
submitted [2]),

- lldb: few unittest breakages (backported already [3]),

- compiler-rt: a few unittest breakages (still need to investigate,
can possibly be related to stand-alone builds, will report bugs later),

- libcxx/libcxxabi: tests broken as reported before [4].

[1]:https://bugs.llvm.org/show_bug.cgi?id=36006
[2]:https://reviews.llvm.org/D42252
[3]:https://bugs.llvm.org/show_bug.cgi?id=35991
[4]:https://bugs.llvm.org/show_bug.cgi?id=35698

-- 
Best regards,
Michał Górny

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

Re: [lldb-dev] Apple LLDB 900.0.64 crash

[Greg Clayton via lldb-dev]

This is a crash that is happening as we are trying to translate DWARF back into 
Clang ASTs. You can enable DWARF logging by doing:

(lldb) log enable -f /tmp/dwarf.log dwarf info

Or add that line to your ~/.lldbinit file.

Then make it crash and we will have a log of what was wrong and might have an 
idea of the type that is causing the problem. If you get this log, there should 
be a line from this code:

  dwarf->GetObjectFile()->GetModule()->LogMessage(
  log, "SymbolFileDWARF::ParseType (die = 0x%8.8x, decl_ctx = %p (die "
   "0x%8.8x)) %s name = '%s')",
  die.GetOffset(), static_cast(context),
  context_die.GetOffset(), die.GetTagAsCString(), die.GetName());

right before it crashed. It might help to reproduce a minimal example that can 
be used to fix this issue.

Remember to remove the "log enable" from your ~/.lldbinit file if you did add 
it, otherwise you will slow down debugging in future sessions.

Greg Clayton


> On Jan 18, 2018, at 6:08 AM, Johan Øverbye via lldb-dev 
>  wrote:
> 
> Hi :)
> 
> I hope this is an appropriate use of this mailing list, my apologies if not. 
> I couldn't find any form to report LLDB bugs and wasn't sure where to ask.
> 
> With a recent update of Xcode I started getting an LLDB crash frequently 
> while attempting to debug. (Not sure exactly which Xcode release sadly.) 
> Sometimes it occurs when the debugger pauses execution (e.g. due to an 
> assertion failure), other times when I attempt to inspect certain variables.
> 
> Here's the call stack of the offending thread:
> 
> Thread 7 Crashed:: RPC packet thread for client tid 7997 (31127)
> 0   com.apple.LLDB.framework  0x000108f98157 
> clang::ClassTemplateSpecializationDecl::Create(clang::ASTContext&, 
> clang::TagTypeKind, clang::DeclContext*, clang::SourceLocation, 
> clang::SourceLocation, clang::ClassTemplateDecl*, 
> llvm::ArrayRef, 
> clang::ClassTemplateSpecializationDecl*) + 71
> 1   com.apple.LLDB.framework  0x00010a6fc39c 
> lldb_private::ClangASTContext::CreateClassTemplateSpecializationDecl(clang::DeclContext*,
>  clang::ClassTemplateDecl*, int, 
> lldb_private::ClangASTContext::TemplateParameterInfos const&) + 308
> 2   com.apple.LLDB.framework  0x00010a546de4 
> DWARFASTParserClang::ParseTypeFromDWARF(lldb_private::SymbolContext const&, 
> DWARFDIE const&, lldb_private::Log*, bool*) + 5890
> 3   com.apple.LLDB.framework  0x00010a6e2623 
> SymbolFileDWARF::ParseType(lldb_private::SymbolContext const&, DWARFDIE 
> const&, bool*) + 171
> 4   com.apple.LLDB.framework  0x00010a6dc33f 
> SymbolFileDWARF::GetTypeForDIE(DWARFDIE const&, bool) + 369
> 5   com.apple.LLDB.framework  0x00010a6dbc6e 
> SymbolFileDWARF::ResolveType(DWARFDIE const&, bool, bool) + 68
> 6   com.apple.LLDB.framework  0x00010a6dbbed 
> SymbolFileDWARF::ResolveTypeUID(unsigned long long) + 45
> 7   com.apple.LLDB.framework  0x00010a759942 
> lldb_private::Type::ResolveClangType(lldb_private::Type::ResolveStateTag) + 
> 154
> 8   com.apple.LLDB.framework  0x00010a759604 
> lldb_private::Type::GetForwardCompilerType() + 26
> 9   com.apple.LLDB.framework  0x00010a59be5f 
> lldb_private::ValueObjectVariable::GetCompilerTypeImpl() + 37
> 10  com.apple.LLDB.framework  0x00010a58cf67 
> lldb_private::ValueObject::MaybeCalculateCompleteType() + 39
> 11  com.apple.LLDB.framework  0x00010a5912dd 
> lldb_private::ValueObject::GetObjectRuntimeLanguage() + 33
> 12  com.apple.LLDB.framework  0x00010a59167b 
> lldb_private::ValueObject::IsRuntimeSupportValue() + 73
> 13  com.apple.LLDB.framework  0x000107c5faec 
> lldb::SBFrame::GetVariables(lldb::SBVariablesOptions const&) + 624
> 14  com.apple.LLDB.framework  0x000107c5fda4 
> lldb::SBFrame::GetVariables(bool, bool, bool, bool, lldb::DynamicValueType) + 
> 208
> 15  lldb-rpc-server   0x000106220aef 
> rpc_server::_ZN4lldb7SBFrame12GetVariablesENS_16DynamicValueTypeE::HandleRPCCall(rpc_common::Connection&,
>  rpc_common::RPCStream&, rpc_common::RPCStream&) + 219
> 16  lldb-rpc-server   0x0001061e662a 
> rpc_common::Connection::PrivateHandleRPCPacket(rpc_common::RPCPacket&, 
> rpc_common::RPCPacket&, bool&) + 506
> 17  lldb-rpc-server   0x0001061e730c 
> rpc_common::Connection::HandleRPCPacket(rpc_common::RPCPacket&) + 62
> 18  lldb-rpc-server   0x0001061ea862 
> Packets::ProcessPackets() + 254
> 19  lldb-rpc-server   0x0001061ea68b 
> Packets::ReadThread() + 187
> 20  lldb-rpc-server   0x0001061ea5cb 
> Packets::RunReadThread(void*) + 9
> 21  libsystem_pthread.dylib   0x7fff7b8906c1 _pthread_body + 340
> 22  libsystem_pthread.dylib   0x7fff7b89056d _pthread_start + 377
> 23  libsystem_pthread.dylib

Re: [lldb-dev] Apple LLDB 900.0.64 crash

[Dimitry Andric via lldb-dev]

Hi Johan,

If it is Apple specific, create a report on the Apple Bug Reporter, at 
https://bugreport.apple.com/ .

If you can reproduce the error with stock lldb, please report it on the LLVM 
bugtracker, at https://bugs.llvm.org/enter_bug.cgi 
.

-Dimitry

> On 18 Jan 2018, at 15:08, Johan Øverbye via lldb-dev 
>  wrote:
> 
> Hi :)
> 
> I hope this is an appropriate use of this mailing list, my apologies if not. 
> I couldn't find any form to report LLDB bugs and wasn't sure where to ask.
> 
> With a recent update of Xcode I started getting an LLDB crash frequently 
> while attempting to debug. (Not sure exactly which Xcode release sadly.) 
> Sometimes it occurs when the debugger pauses execution (e.g. due to an 
> assertion failure), other times when I attempt to inspect certain variables.
> 
> Here's the call stack of the offending thread:
> 
> Thread 7 Crashed:: RPC packet thread for client tid 7997 (31127)
> 0   com.apple.LLDB.framework  0x000108f98157 
> clang::ClassTemplateSpecializationDecl::Create(clang::ASTContext&, 
> clang::TagTypeKind, clang::DeclContext*, clang::SourceLocation, 
> clang::SourceLocation, clang::ClassTemplateDecl*, 
> llvm::ArrayRef, 
> clang::ClassTemplateSpecializationDecl*) + 71
> 1   com.apple.LLDB.framework  0x00010a6fc39c 
> lldb_private::ClangASTContext::CreateClassTemplateSpecializationDecl(clang::DeclContext*,
>  clang::ClassTemplateDecl*, int, 
> lldb_private::ClangASTContext::TemplateParameterInfos const&) + 308
> 2   com.apple.LLDB.framework  0x00010a546de4 
> DWARFASTParserClang::ParseTypeFromDWARF(lldb_private::SymbolContext const&, 
> DWARFDIE const&, lldb_private::Log*, bool*) + 5890
> 3   com.apple.LLDB.framework  0x00010a6e2623 
> SymbolFileDWARF::ParseType(lldb_private::SymbolContext const&, DWARFDIE 
> const&, bool*) + 171
> 4   com.apple.LLDB.framework  0x00010a6dc33f 
> SymbolFileDWARF::GetTypeForDIE(DWARFDIE const&, bool) + 369
> 5   com.apple.LLDB.framework  0x00010a6dbc6e 
> SymbolFileDWARF::ResolveType(DWARFDIE const&, bool, bool) + 68
> 6   com.apple.LLDB.framework  0x00010a6dbbed 
> SymbolFileDWARF::ResolveTypeUID(unsigned long long) + 45
> 7   com.apple.LLDB.framework  0x00010a759942 
> lldb_private::Type::ResolveClangType(lldb_private::Type::ResolveStateTag) + 
> 154
> 8   com.apple.LLDB.framework  0x00010a759604 
> lldb_private::Type::GetForwardCompilerType() + 26
> 9   com.apple.LLDB.framework  0x00010a59be5f 
> lldb_private::ValueObjectVariable::GetCompilerTypeImpl() + 37
> 10  com.apple.LLDB.framework  0x00010a58cf67 
> lldb_private::ValueObject::MaybeCalculateCompleteType() + 39
> 11  com.apple.LLDB.framework  0x00010a5912dd 
> lldb_private::ValueObject::GetObjectRuntimeLanguage() + 33
> 12  com.apple.LLDB.framework  0x00010a59167b 
> lldb_private::ValueObject::IsRuntimeSupportValue() + 73
> 13  com.apple.LLDB.framework  0x000107c5faec 
> lldb::SBFrame::GetVariables(lldb::SBVariablesOptions const&) + 624
> 14  com.apple.LLDB.framework  0x000107c5fda4 
> lldb::SBFrame::GetVariables(bool, bool, bool, bool, lldb::DynamicValueType) + 
> 208
> 15  lldb-rpc-server   0x000106220aef 
> rpc_server::_ZN4lldb7SBFrame12GetVariablesENS_16DynamicValueTypeE::HandleRPCCall(rpc_common::Connection&,
>  rpc_common::RPCStream&, rpc_common::RPCStream&) + 219
> 16  lldb-rpc-server   0x0001061e662a 
> rpc_common::Connection::PrivateHandleRPCPacket(rpc_common::RPCPacket&, 
> rpc_common::RPCPacket&, bool&) + 506
> 17  lldb-rpc-server   0x0001061e730c 
> rpc_common::Connection::HandleRPCPacket(rpc_common::RPCPacket&) + 62
> 18  lldb-rpc-server   0x0001061ea862 
> Packets::ProcessPackets() + 254
> 19  lldb-rpc-server   0x0001061ea68b 
> Packets::ReadThread() + 187
> 20  lldb-rpc-server   0x0001061ea5cb 
> Packets::RunReadThread(void*) + 9
> 21  libsystem_pthread.dylib   0x7fff7b8906c1 _pthread_body + 340
> 22  libsystem_pthread.dylib   0x7fff7b89056d _pthread_start + 377
> 23  libsystem_pthread.dylib   0x7fff7b88fc5d thread_start + 13
> 
> The full LLDB crash dump can be downloaded here: 
> https://www.dropbox.com/s/87tpcb31t10679z/lldb-rpc-server_2018-01-18-134410_Johans-MacBook-Pro.crash?dl=0
>  
> 
> 
> The (Apple) LLDB version is lldb-900.0.64. Not sure whether/how this 
> corresponds to "official" LLDB version numbers.
> 
> Unfortunately I'm unable to share the code for confidentiality reasons. I'll 
> attempt to isolate the issue but I thought I'd ask here in case it's a known 
> issue or the cause is obvious.
> 
> 
> Thanks,
> 
> 

Re: [lldb-dev] [llvm-dev] [Release-testers] [6.0.0 Release] Release Candidate 1 tagged

[Dimitry Andric via lldb-dev]

On 18 Jan 2018, at 15:03, Jonas Hahnfeld  wrote:
> 
> Am 2018-01-18 14:55, schrieb Dimitry Andric via llvm-dev:
>> On 17 Jan 2018, at 18:53, Hans Wennborg via Release-testers
>>  wrote:
>>> Start your engines; 6.0.0-rc1 was just tagged.
>>> I know there are still open blockers and it's early in the process in
>>> a way, but I'd like to find out where we are. Please run the test
>>> script, let me know the results, and upload binaries.
>> At the moment I can't compile openmp, since it errors out on libomptarget:
>> /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:50:10:
>> error: use of undeclared identifier 'malloc'
>>rc = malloc(size);
>> ^
>> /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:76:5:
>> error: use of undeclared identifier 'free'
>>free(device_ptr);
>>^
>> /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:163:20:
>> error: use of undeclared identifier 'malloc'
>>void *buffer = malloc(length);
>>   ^
>> I'm trying a local fix here, namely including  at the top of the 
>> file.
> 
> Argh, I have missed that header. Adding  sounds like the right 
> solution, can you submit a patch or directly commit to SVN if it works for 
> you?

I added  to api.cpp, interface.cpp and rtl.cpp, in r322869.  Hans, 
could you please merge it to release_60, or shall I do it?

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Questions about the LLDB testsuite and improving its reliability

[Pavel Labath via lldb-dev]

On 18 January 2018 at 17:52, Adrian Prantl  wrote:
>
>
>> On Jan 18, 2018, at 5:07 AM, Pavel Labath  wrote:
>>
>> Looks like I missed a party. :)
>>
>> I'll try to give my thoughts on some of the things that were said here:
>>
>>> make -C
>> I don't think make -C does what you think it does. "make -C foo" is
>> basically equivalent to "cd foo && make", which is what we are doing
>> now already. Of course, you can make this work, but you would have to
>> pass an extra OUTDIR=... argument to make and then modify the
>> Makefiles to reference $(OUTDIR) for its outputs:
>> $(OUTDIR)/a.out: main.cc
>>  $(CC) -o $(OUTDIR)/a.out main.cc ...
>>
>> The standard way of doing an out-of-tree build with make is to have
>> the Makefile in the build-directory and to set the magic VPATH
>> variable in the Makefile (or as a part of make invocation). VPATH
>> alters make's search path, so when searching for a dependency foo and
>> the foo is not present in the current (build) directory, it will go
>> searching for it in the VPATH (source) directory. You still need to be
>> careful about paths in the command line (generally this means using
>> make variables like $@ and $< instead of bare file names), but our
>> makefiles are generally pretty good at this already. We even have a
>> couple of makefiles using VPATH already (see TestConcurrentEvents) --
>> Todd added this to speed up the build by spreading out tests over
>> different folders while sharing sources (the serial execution
>> problem).
>>
> This is of course correct. Thanks for pointing this out and for outlining all 
> the necessary changes!
>
>> I still fully support being able to build the tests out of tree, I
>> just think it may be a bit more involved than you realise.
>
> Sounds good.
>
>>
>>> cmake
>> I agree that using cmake for building tests would some things simpler.
>> Building fully working executables is fairly tricky, especially when
>> you're cross-compiling. Take test/testcases/Android.rules for example.
>> This is basically a reimplementation of the android cmake toolchain
>> file distributed with the android ndk. If we had cmake for building
>> tests we could delete all of that and replace it with
>> -DCMAKE_TOOLCHAIN_FILE=$(ANDROID_NDK_HOME)/android.toolchain.cmake.
>> However, I only had to write Android.rules just once, so it's not that
>> big of a deal for me.
>>
>>> explicit RUN lines:
>> Yes, it's true that all you need is custom CXXFLAGS (and LDFLAGS), but
>> those CXX flags could be quite complex. I'm not really opposed to
>> that, but I don't see any immediate benefit either (the only impact
>> for me would be that I'd have to translate Android.rules to python).
>>
>>> running clean after every test
>> Currently we must run "make clean" after every test because make does
>> not track the changes in it's arguments. So, if you first run "make
>> MAKE_DWO=NO" and then "make MAKE_DWO=YES", make will happily declare
>> that it has nothing to do without building the DWO binary. (This will
>> go away if we run each test variant in a separate directory).
>>
>> I don't have any data, but I would expect that running make upfront
>> would make a significant performance improvement on windows (spinning
>> up tons of processes and creating/deleting a bunch of files tends to
>> be much slower there), but to have no noticable difference on other
>> platforms.
>>
>
> I have not thought of Windows being a possible bottleneck. That sounds 
> plausible. I'm still wondering how useful incremental builds for the 
> testsuite are going to be. When I'm looking at our bots, almost all incoming 
> commits are not in LLDB, but in LLVM or Clang. If we are modeling 
> dependencies correctly, then each of these commits that changes the compiler 
> should still trigger a full rebuild of all testcases, even with CMake. The 
> only situation where incremental builds would be useful are for a 
> configuration where we are building the LLDB testsuite against a fixed 
> compiler, such as a released/stable version of clang or gcc. That's not to 
> say that that isn't an important use-case, too, of course, but it's not how 
> the bots on green dragon are configured at the moment.
>
> -- adrian

It wouldn't speed up the bots, but it may make the workflow of an lldb
developer (who  changes only lldb code most of the time) faster.
However, that doesn't matter I guess, as that's not the direction
we're going now.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Questions about the LLDB testsuite and improving its reliability

[Adrian Prantl via lldb-dev]

> On Jan 18, 2018, at 5:07 AM, Pavel Labath  wrote:
> 
> Looks like I missed a party. :)
> 
> I'll try to give my thoughts on some of the things that were said here:
> 
>> make -C
> I don't think make -C does what you think it does. "make -C foo" is
> basically equivalent to "cd foo && make", which is what we are doing
> now already. Of course, you can make this work, but you would have to
> pass an extra OUTDIR=... argument to make and then modify the
> Makefiles to reference $(OUTDIR) for its outputs:
> $(OUTDIR)/a.out: main.cc
>  $(CC) -o $(OUTDIR)/a.out main.cc ...
> 
> The standard way of doing an out-of-tree build with make is to have
> the Makefile in the build-directory and to set the magic VPATH
> variable in the Makefile (or as a part of make invocation). VPATH
> alters make's search path, so when searching for a dependency foo and
> the foo is not present in the current (build) directory, it will go
> searching for it in the VPATH (source) directory. You still need to be
> careful about paths in the command line (generally this means using
> make variables like $@ and $< instead of bare file names), but our
> makefiles are generally pretty good at this already. We even have a
> couple of makefiles using VPATH already (see TestConcurrentEvents) --
> Todd added this to speed up the build by spreading out tests over
> different folders while sharing sources (the serial execution
> problem).
> 
This is of course correct. Thanks for pointing this out and for outlining all 
the necessary changes!

> I still fully support being able to build the tests out of tree, I
> just think it may be a bit more involved than you realise.

Sounds good.

> 
>> cmake
> I agree that using cmake for building tests would some things simpler.
> Building fully working executables is fairly tricky, especially when
> you're cross-compiling. Take test/testcases/Android.rules for example.
> This is basically a reimplementation of the android cmake toolchain
> file distributed with the android ndk. If we had cmake for building
> tests we could delete all of that and replace it with
> -DCMAKE_TOOLCHAIN_FILE=$(ANDROID_NDK_HOME)/android.toolchain.cmake.
> However, I only had to write Android.rules just once, so it's not that
> big of a deal for me.
> 
>> explicit RUN lines:
> Yes, it's true that all you need is custom CXXFLAGS (and LDFLAGS), but
> those CXX flags could be quite complex. I'm not really opposed to
> that, but I don't see any immediate benefit either (the only impact
> for me would be that I'd have to translate Android.rules to python).
> 
>> running clean after every test
> Currently we must run "make clean" after every test because make does
> not track the changes in it's arguments. So, if you first run "make
> MAKE_DWO=NO" and then "make MAKE_DWO=YES", make will happily declare
> that it has nothing to do without building the DWO binary. (This will
> go away if we run each test variant in a separate directory).
> 
> I don't have any data, but I would expect that running make upfront
> would make a significant performance improvement on windows (spinning
> up tons of processes and creating/deleting a bunch of files tends to
> be much slower there), but to have no noticable difference on other
> platforms.
> 

I have not thought of Windows being a possible bottleneck. That sounds 
plausible. I'm still wondering how useful incremental builds for the testsuite 
are going to be. When I'm looking at our bots, almost all incoming commits are 
not in LLDB, but in LLVM or Clang. If we are modeling dependencies correctly, 
then each of these commits that changes the compiler should still trigger a 
full rebuild of all testcases, even with CMake. The only situation where 
incremental builds would be useful are for a configuration where we are 
building the LLDB testsuite against a fixed compiler, such as a released/stable 
version of clang or gcc. That's not to say that that isn't an important 
use-case, too, of course, but it's not how the bots on green dragon are 
configured at the moment.

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

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

[Pavel Labath via lldb-dev]

Thank you for all the responses. Unfortunately I wasn't able to make
any progress on creating the patches today. I'll be sure to add
everyone who expressed interest here to the phabricator diff once I
have them ready.

Jonas, do you have any dsymutil patches I can look at? I am interested
in seeing what kind of interfaces are you using, particularly on the
reading side. I think the current DWARFAcceleratorTable interface will
need to be redesigned a bit if we want it to fit the dwarf5 tables as
well.

On 17 January 2018 at 20:52, Eric Christopher via lldb-dev
 wrote:
> FWIW I'm completely on board with everything Adrian has said in this thread
> :)
>
> -eric
>
> On Wed, Jan 17, 2018 at 11:00 AM Adrian Prantl via llvm-dev
>  wrote:
>>
>>
>>
>> > On Jan 17, 2018, at 9:20 AM, Jonas Devlieghere via llvm-dev
>> >  wrote:
>> >
>> > As mentioned by Adrian in the comment you linked, I too am looking at
>> > DWARFv5
>> > accelerator tables in LLVM.
>> >
>> > To give you some background: my motivation is that I want to upstream
>> > support
>> > for (Apple style) accelerator tables in llvm-dsymutil,
>>
>> Some background for the benefit of everyone who may not be aware of the
>> genesis of the DWARF v5 accelerator tables:
>>
>> DWARF v5 accelerator tables are a direct evolution of the "Apple"
>> accelerator tables that are implemented in LLVM (after going through the
>> standardization process and being reworked/generalized there), so we hope
>> that the implementation can at least share some common interfaces with the
>> existing Apple accelerator table implementation where this makes sense.
>>
>> -- adrian
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Apple LLDB 900.0.64 crash

[Johan Øverbye via lldb-dev]

Hi :)

I hope this is an appropriate use of this mailing list, my apologies if not. I 
couldn't find any form to report LLDB bugs and wasn't sure where to ask.

With a recent update of Xcode I started getting an LLDB crash frequently while 
attempting to debug. (Not sure exactly which Xcode release sadly.) Sometimes it 
occurs when the debugger pauses execution (e.g. due to an assertion failure), 
other times when I attempt to inspect certain variables.

Here's the call stack of the offending thread:

Thread 7 Crashed:: RPC packet thread for client tid 7997 (31127)
0   com.apple.LLDB.framework0x000108f98157 
clang::ClassTemplateSpecializationDecl::Create(clang::ASTContext&, 
clang::TagTypeKind, clang::DeclContext*, clang::SourceLocation, 
clang::SourceLocation, clang::ClassTemplateDecl*, 
llvm::ArrayRef, 
clang::ClassTemplateSpecializationDecl*) + 71
1   com.apple.LLDB.framework0x00010a6fc39c 
lldb_private::ClangASTContext::CreateClassTemplateSpecializationDecl(clang::DeclContext*,
 clang::ClassTemplateDecl*, int, 
lldb_private::ClangASTContext::TemplateParameterInfos const&) + 308
2   com.apple.LLDB.framework0x00010a546de4 
DWARFASTParserClang::ParseTypeFromDWARF(lldb_private::SymbolContext const&, 
DWARFDIE const&, lldb_private::Log*, bool*) + 5890
3   com.apple.LLDB.framework0x00010a6e2623 
SymbolFileDWARF::ParseType(lldb_private::SymbolContext const&, DWARFDIE const&, 
bool*) + 171
4   com.apple.LLDB.framework0x00010a6dc33f 
SymbolFileDWARF::GetTypeForDIE(DWARFDIE const&, bool) + 369
5   com.apple.LLDB.framework0x00010a6dbc6e 
SymbolFileDWARF::ResolveType(DWARFDIE const&, bool, bool) + 68
6   com.apple.LLDB.framework0x00010a6dbbed 
SymbolFileDWARF::ResolveTypeUID(unsigned long long) + 45
7   com.apple.LLDB.framework0x00010a759942 
lldb_private::Type::ResolveClangType(lldb_private::Type::ResolveStateTag) + 154
8   com.apple.LLDB.framework0x00010a759604 
lldb_private::Type::GetForwardCompilerType() + 26
9   com.apple.LLDB.framework0x00010a59be5f 
lldb_private::ValueObjectVariable::GetCompilerTypeImpl() + 37
10  com.apple.LLDB.framework0x00010a58cf67 
lldb_private::ValueObject::MaybeCalculateCompleteType() + 39
11  com.apple.LLDB.framework0x00010a5912dd 
lldb_private::ValueObject::GetObjectRuntimeLanguage() + 33
12  com.apple.LLDB.framework0x00010a59167b 
lldb_private::ValueObject::IsRuntimeSupportValue() + 73
13  com.apple.LLDB.framework0x000107c5faec 
lldb::SBFrame::GetVariables(lldb::SBVariablesOptions const&) + 624
14  com.apple.LLDB.framework0x000107c5fda4 
lldb::SBFrame::GetVariables(bool, bool, bool, bool, lldb::DynamicValueType) + 
208
15  lldb-rpc-server 0x000106220aef 
rpc_server::_ZN4lldb7SBFrame12GetVariablesENS_16DynamicValueTypeE::HandleRPCCall(rpc_common::Connection&,
 rpc_common::RPCStream&, rpc_common::RPCStream&) + 219
16  lldb-rpc-server 0x0001061e662a 
rpc_common::Connection::PrivateHandleRPCPacket(rpc_common::RPCPacket&, 
rpc_common::RPCPacket&, bool&) + 506
17  lldb-rpc-server 0x0001061e730c 
rpc_common::Connection::HandleRPCPacket(rpc_common::RPCPacket&) + 62
18  lldb-rpc-server 0x0001061ea862 
Packets::ProcessPackets() + 254
19  lldb-rpc-server 0x0001061ea68b 
Packets::ReadThread() + 187
20  lldb-rpc-server 0x0001061ea5cb 
Packets::RunReadThread(void*) + 9
21  libsystem_pthread.dylib 0x7fff7b8906c1 _pthread_body + 340
22  libsystem_pthread.dylib 0x7fff7b89056d _pthread_start + 377
23  libsystem_pthread.dylib 0x7fff7b88fc5d thread_start + 13

The full LLDB crash dump can be downloaded here: 
https://www.dropbox.com/s/87tpcb31t10679z/lldb-rpc-server_2018-01-18-134410_Johans-MacBook-Pro.crash?dl=0
 


The (Apple) LLDB version is lldb-900.0.64. Not sure whether/how this 
corresponds to "official" LLDB version numbers.

Unfortunately I'm unable to share the code for confidentiality reasons. I'll 
attempt to isolate the issue but I thought I'd ask here in case it's a known 
issue or the cause is obvious.


Thanks,

Johan Øverbye
-- 
This message, including any attachments, may contain confidential or 
privileged information and is intended solely for the addressee. If you are 
not an intended recipient, please notify the sender and delete this message 
and any back-up copies from your systems. We love trees! Please do not 
print this email unless absolutely necessary, thank you. String Applied 
Technologies is a limited company registered in England and Wales. 
Registered number: 08962109. Registered office: The Bradfield Centre, 184, 
Cambridge 

Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 1 tagged

[Dimitry Andric via lldb-dev]

On 17 Jan 2018, at 18:53, Hans Wennborg via Release-testers 
 wrote:
> Start your engines; 6.0.0-rc1 was just tagged.
> 
> I know there are still open blockers and it's early in the process in
> a way, but I'd like to find out where we are. Please run the test
> script, let me know the results, and upload binaries.

At the moment I can't compile openmp, since it errors out on libomptarget:

/home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:50:10:
 error: use of undeclared identifier 'malloc'
rc = malloc(size);
 ^
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:76:5:
 error: use of undeclared identifier 'free'
free(device_ptr);
^
/home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:163:20:
 error: use of undeclared identifier 'malloc'
void *buffer = malloc(length);
   ^

I'm trying a local fix here, namely including  at the top of the file.

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Questions about the LLDB testsuite and improving its reliability

[Pavel Labath via lldb-dev]

Looks like I missed a party. :)

I'll try to give my thoughts on some of the things that were said here:

> make -C
I don't think make -C does what you think it does. "make -C foo" is
basically equivalent to "cd foo && make", which is what we are doing
now already. Of course, you can make this work, but you would have to
pass an extra OUTDIR=... argument to make and then modify the
Makefiles to reference $(OUTDIR) for its outputs:
$(OUTDIR)/a.out: main.cc
  $(CC) -o $(OUTDIR)/a.out main.cc ...

The standard way of doing an out-of-tree build with make is to have
the Makefile in the build-directory and to set the magic VPATH
variable in the Makefile (or as a part of make invocation). VPATH
alters make's search path, so when searching for a dependency foo and
the foo is not present in the current (build) directory, it will go
searching for it in the VPATH (source) directory. You still need to be
careful about paths in the command line (generally this means using
make variables like $@ and $< instead of bare file names), but our
makefiles are generally pretty good at this already. We even have a
couple of makefiles using VPATH already (see TestConcurrentEvents) --
Todd added this to speed up the build by spreading out tests over
different folders while sharing sources (the serial execution
problem).

I still fully support being able to build the tests out of tree, I
just think it may be a bit more involved than you realise.

> cmake
I agree that using cmake for building tests would some things simpler.
Building fully working executables is fairly tricky, especially when
you're cross-compiling. Take test/testcases/Android.rules for example.
This is basically a reimplementation of the android cmake toolchain
file distributed with the android ndk. If we had cmake for building
tests we could delete all of that and replace it with
-DCMAKE_TOOLCHAIN_FILE=$(ANDROID_NDK_HOME)/android.toolchain.cmake.
However, I only had to write Android.rules just once, so it's not that
big of a deal for me.

> explicit RUN lines:
Yes, it's true that all you need is custom CXXFLAGS (and LDFLAGS), but
those CXX flags could be quite complex. I'm not really opposed to
that, but I don't see any immediate benefit either (the only impact
for me would be that I'd have to translate Android.rules to python).

> running clean after every test
Currently we must run "make clean" after every test because make does
not track the changes in it's arguments. So, if you first run "make
MAKE_DWO=NO" and then "make MAKE_DWO=YES", make will happily declare
that it has nothing to do without building the DWO binary. (This will
go away if we run each test variant in a separate directory).

I don't have any data, but I would expect that running make upfront
would make a significant performance improvement on windows (spinning
up tons of processes and creating/deleting a bunch of files tends to
be much slower there), but to have no noticable difference on other
platforms.



On 18 January 2018 at 01:45, Adrian Prantl via lldb-dev
 wrote:
>
>
>> On Jan 17, 2018, at 3:26 PM, Greg Clayton via lldb-dev 
>>  wrote:
>>
>> Everything sounds good on this thread. My two cents:
>>
>> We should add some post verification after each test that looks for file 
>> that are left over after the "clean" phase. This can help us catch the tests 
>> that aren't cleaning up after themselves. This will help us weed out the bad 
>> tests and fix this ASAP. This can be done both for in tree and out of tree 
>> solutions to verify there is no source polution.
>>
>> We can easily move build artifacts out of the source tree. Running the test 
>> suite remotely via "lldb-server platform" has code that creates directories 
>> for each test in the platform working directory. If the test runs fine and 
>> passes, it cleans up the entire numbered test directory, else it leaves the 
>> numbered directory there so we can debug any issues. Shouldn't be hard to 
>> enable this.
>
> For completeness, I looked at this and it doesn't look like that is how it 
> works. My understanding (and keep in mind that this is the first time I am 
> looking at this code so I might be misunderstanding something here) is that 
> the remote platform support works by building the test on the host in-tree 
> and then _RemoteProcess.launch() ships over only the binary when called from 
> Base.spawnSubprocess().
>
> That's not a big deal, though. I will introduce the concept of a build 
> directory (which has to be separate from the remote platform working 
> directory) and find a way to pass the source directory to runBuildCommands().
>
> -- adrian
>
>>
>> I like the current default of having a new directory with the time and data 
>> with results inside as it allows comparison of one test suite run to another.
>>
>> Switching build systems to cmake is fine if someone has the energy to do it, 
>> that would be great. I don't see why we would go with a lit based 

Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 1 tagged

[Brian Cain via lldb-dev]

Uploaded

afeb7f66eedd4d576ba8df9b4a551bb1908186e6
clang+llvm-6.0.0-rc1-linux-x86_64-sles11.3.tar.xz


On Wed, Jan 17, 2018 at 11:53 AM, Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:

> Dear testers,
>
> Start your engines; 6.0.0-rc1 was just tagged.
>
> I know there are still open blockers and it's early in the process in
> a way, but I'd like to find out where we are. Please run the test
> script, let me know the results, and upload binaries.
>
> Thanks,
> Hans
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>



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

Re: [lldb-dev] [cfe-dev] [6.0.0 Release] Release Candidate 1 tagged

[Dimitry Andric via lldb-dev]

On 17 Jan 2018, at 18:53, Hans Wennborg via cfe-dev  
wrote:
> 
> Start your engines; 6.0.0-rc1 was just tagged.
> 
> I know there are still open blockers and it's early in the process in
> a way, but I'd like to find out where we are.

For an overview of what failed in the FreeBSD ports collection, with a 6.0.0 
snapshot corresponding to trunk r321545, see here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224669

Roughly 24,000 ports were built, 500 failed, and those caused ~4,400 other 
ports not to be built.

A number of crashes were already reported on the LLVM bugtracker, and some 
other important packages were already fixed.  But all is definitely not clear 
yet. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 1 tagged

[Diana Picus via lldb-dev]

Hi,

Uploaded ARM & AArch64:
b84b25397a4ea479d08c056b20582fd0a8e16bb6
clang+llvm-6.0.0-rc1-aarch64-linux-gnu.tar.xz
c19100cf7fb1d0fea80ed3e761bfd293e807b59a
clang+llvm-6.0.0-rc1-armv7a-linux-gnueabihf.tar.xz

I am seeing some failures in compiler-rt (ARM, AArch64) and libcxx
(just ARM), for which I have filed PR35996 and PR35997.

Cheers,
Diana

On 18 January 2018 at 04:17, Bero Rosenkränzer via Release-testers
 wrote:
> We're now using it as the main compiler in the OpenMandriva
> development builds -- no issues so far (after rebuilding a couple of
> key packages for testing).
>
> ttyl
> bero
>
> On 17 January 2018 at 18:53, Hans Wennborg via Release-testers
>  wrote:
>> Dear testers,
>>
>> Start your engines; 6.0.0-rc1 was just tagged.
>>
>> I know there are still open blockers and it's early in the process in
>> a way, but I'd like to find out where we are. Please run the test
>> script, let me know the results, and upload binaries.
>>
>> Thanks,
>> Hans
>> ___
>> Release-testers mailing list
>> release-test...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 35991] [lldb] Please backport LLDB test regression fixes to 6.0 branch

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=35991

Hans Wennborg  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||h...@chromium.org
 Resolution|--- |FIXED

--- Comment #1 from Hans Wennborg  ---
>   r322081 [test] Fix tests to use more portable LLVM_ENABLE_ZLIB

Merged in r322833.

>   r321932 [test] Use full PATH lookup for tools

Merged in r322832.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev