Re: [lldb-dev] [Release-testers] [4.0.0 Release] Relase Candidate 1 has been tagged

2017-01-19 Thread Dimitry Andric via lldb-dev 
On 18 Jan 2017, at 16:45, Hans Wennborg via Release-testers 
 wrote:
> Dear testers,
> 
> 4.0.0-rc1 was just tagged from the branch, with r292377.
> 
> There are still open merge requests and bugs, but I'd like to get the
> testing started to see what issues come up.

Unfortunately no builds for FreeBSD yet, as the Phase1 clang segfaults when 
building AsmParser.cpp:

[  1%] Building CXX object 
lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o
cd 
/home/dim/llvm-4.0.0/rc1/Phase2/Release/llvmCore-4.0.0-rc1.obj/lib/MC/MCParser 
&& /home/dim/llvm-4.0
.0/rc1/Phase1/Release/llvmCore-4.0.0-rc1.install/usr/local/bin/clang++   
-DGTEST_HAS_RTTI=0 -D__STDC_CO
NSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-I/home/dim/llvm-4.0.0/rc1/Phase2/Release/ll
vmCore-4.0.0-rc1.obj/lib/MC/MCParser 
-I/home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser -I/home/dim/ll
vm-4.0.0/rc1/Phase2/Release/llvmCore-4.0.0-rc1.obj/include 
-I/home/dim/llvm-4.0.0/rc1/llvm.src/include
-I/usr/local/include  -fPIC -fvisibility-inlines-hidden -Wall -W 
-Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long 
-Wcovered-switch-default -Wnon-virtua
l-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -Werror=date-time 
-std=c++11 -ffunction-sections -
fdata-sections -O3 -DNDEBUG-fno-exceptions -fno-rtti -o 
CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o
 -c /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp
/home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2043:25: 
warning: variable 'CppHashLocL
ineNo' is uninitialized when used here [-Wuninitialized]
LastQueryLine = CppHashLocLineNo;
^~~~
/home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2036:32: note: 
initialize the variable
'CppHashLocLineNo' to silence this warning
  unsigned CppHashLocLineNo;
   ^
= 0
/home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2155:71: 
warning: variable 'LineNo' is
uninitialized when used here [-Wuninitialized]
  SMDiagnostic NewDiag(*Diag.getSourceMgr(), Diag.getLoc(), Filename, LineNo,
  ^~
/home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2152:13: note: 
initialize the variable
'LineNo' to silence this warning
  int LineNo =
^
 = 0
clang-4.0: error: unable to execute command: Segmentation fault (core dumped)
clang-4.0: error: clang frontend command failed due to signal (use -v to see 
invocation)
clang version 4.0.0 (tags/RELEASE_400/rc1)
Target: i386-unknown-freebsd10.3
Thread model: posix
InstalledDir: 
/home/dim/llvm-4.0.0/rc1/Phase1/Release/llvmCore-4.0.0-rc1.install/usr/local/bin
clang-4.0: note: diagnostic msg: PLEASE submit a bug report to 
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and 
associated run script.
clang-4.0: note: diagnostic msg:


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-4.0: note: diagnostic msg: /home/dim/tmp/AsmParser-c3ca7e.cpp
clang-4.0: note: diagnostic msg: /home/dim/tmp/AsmParser-c3ca7e.sh
clang-4.0: note: diagnostic msg:


gmake[2]: *** [lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/build.make:87: 
lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o] Error 254

I thought this might be because r292133 was not merged yet, but I was wrong 
about that, it *is* merged.

So I will have to investigate why it crashes here.

-Dimitry



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

Re: [lldb-dev] [Release-testers] [4.0.0 Release] Relase Candidate 1 has been tagged

2017-01-19 Thread Hans Wennborg via lldb-dev 
On Thu, Jan 19, 2017 at 12:12 AM, Dimitry Andric  wrote:
> On 18 Jan 2017, at 16:45, Hans Wennborg via Release-testers 
>  wrote:
>> Dear testers,
>>
>> 4.0.0-rc1 was just tagged from the branch, with r292377.
>>
>> There are still open merge requests and bugs, but I'd like to get the
>> testing started to see what issues come up.
>
> Unfortunately no builds for FreeBSD yet, as the Phase1 clang segfaults when 
> building AsmParser.cpp:
>
> [  1%] Building CXX object 
> lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o
> cd 
> /home/dim/llvm-4.0.0/rc1/Phase2/Release/llvmCore-4.0.0-rc1.obj/lib/MC/MCParser
>  && /home/dim/llvm-4.0
> .0/rc1/Phase1/Release/llvmCore-4.0.0-rc1.install/usr/local/bin/clang++   
> -DGTEST_HAS_RTTI=0 -D__STDC_CO
> NSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
> -I/home/dim/llvm-4.0.0/rc1/Phase2/Release/ll
> vmCore-4.0.0-rc1.obj/lib/MC/MCParser 
> -I/home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser -I/home/dim/ll
> vm-4.0.0/rc1/Phase2/Release/llvmCore-4.0.0-rc1.obj/include 
> -I/home/dim/llvm-4.0.0/rc1/llvm.src/include
> -I/usr/local/include  -fPIC -fvisibility-inlines-hidden -Wall -W 
> -Wno-unused-parameter -Wwrite-strings
> -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long 
> -Wcovered-switch-default -Wnon-virtua
> l-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -Werror=date-time 
> -std=c++11 -ffunction-sections -
> fdata-sections -O3 -DNDEBUG-fno-exceptions -fno-rtti -o 
> CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o
>  -c /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp
> /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2043:25: 
> warning: variable 'CppHashLocL
> ineNo' is uninitialized when used here [-Wuninitialized]
> LastQueryLine = CppHashLocLineNo;
> ^~~~
> /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2036:32: 
> note: initialize the variable
> 'CppHashLocLineNo' to silence this warning
>   unsigned CppHashLocLineNo;
>^
> = 0
> /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2155:71: 
> warning: variable 'LineNo' is
> uninitialized when used here [-Wuninitialized]
>   SMDiagnostic NewDiag(*Diag.getSourceMgr(), Diag.getLoc(), Filename, LineNo,
>   ^~
> /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2152:13: 
> note: initialize the variable
> 'LineNo' to silence this warning
>   int LineNo =
> ^
>  = 0
> clang-4.0: error: unable to execute command: Segmentation fault (core dumped)
> clang-4.0: error: clang frontend command failed due to signal (use -v to see 
> invocation)
> clang version 4.0.0 (tags/RELEASE_400/rc1)
> Target: i386-unknown-freebsd10.3
> Thread model: posix
> InstalledDir: 
> /home/dim/llvm-4.0.0/rc1/Phase1/Release/llvmCore-4.0.0-rc1.install/usr/local/bin
> clang-4.0: note: diagnostic msg: PLEASE submit a bug report to 
> http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, 
> and associated run script.
> clang-4.0: note: diagnostic msg:
> 
>
> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
> Preprocessed source(s) and associated run script(s) are located at:
> clang-4.0: note: diagnostic msg: /home/dim/tmp/AsmParser-c3ca7e.cpp
> clang-4.0: note: diagnostic msg: /home/dim/tmp/AsmParser-c3ca7e.sh
> clang-4.0: note: diagnostic msg:
>
> 
> gmake[2]: *** [lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/build.make:87: 
> lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o] Error 254
>
> I thought this might be because r292133 was not merged yet, but I was wrong 
> about that, it *is* merged.
>
> So I will have to investigate why it crashes here.

Is this PR31692 that you filed today?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [4.0.0 Release] Relase Candidate 1 has been tagged

2017-01-19 Thread Dimitry Andric via lldb-dev 
On 19 Jan 2017, at 16:40, Hans Wennborg  wrote:
> 
> On Thu, Jan 19, 2017 at 12:12 AM, Dimitry Andric  wrote:
>> On 18 Jan 2017, at 16:45, Hans Wennborg via Release-testers 
>>  wrote:
>>> Dear testers,
>>> 
>>> 4.0.0-rc1 was just tagged from the branch, with r292377.
>>> 
>>> There are still open merge requests and bugs, but I'd like to get the
>>> testing started to see what issues come up.
>> 
>> Unfortunately no builds for FreeBSD yet, as the Phase1 clang segfaults when 
>> building AsmParser.cpp:
>> 
>> [  1%] Building CXX object 
>> lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o
>> cd 
>> /home/dim/llvm-4.0.0/rc1/Phase2/Release/llvmCore-4.0.0-rc1.obj/lib/MC/MCParser
>>  && /home/dim/llvm-4.0
>> .0/rc1/Phase1/Release/llvmCore-4.0.0-rc1.install/usr/local/bin/clang++   
>> -DGTEST_HAS_RTTI=0 -D__STDC_CO
>> NSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
>> -I/home/dim/llvm-4.0.0/rc1/Phase2/Release/ll
>> vmCore-4.0.0-rc1.obj/lib/MC/MCParser 
>> -I/home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser -I/home/dim/ll
>> vm-4.0.0/rc1/Phase2/Release/llvmCore-4.0.0-rc1.obj/include 
>> -I/home/dim/llvm-4.0.0/rc1/llvm.src/include
>> -I/usr/local/include  -fPIC -fvisibility-inlines-hidden -Wall -W 
>> -Wno-unused-parameter -Wwrite-strings
>> -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long 
>> -Wcovered-switch-default -Wnon-virtua
>> l-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -Werror=date-time 
>> -std=c++11 -ffunction-sections -
>> fdata-sections -O3 -DNDEBUG-fno-exceptions -fno-rtti -o 
>> CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o
>> -c /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp
>> /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2043:25: 
>> warning: variable 'CppHashLocL
>> ineNo' is uninitialized when used here [-Wuninitialized]
>>LastQueryLine = CppHashLocLineNo;
>>^~~~
>> /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2036:32: 
>> note: initialize the variable
>> 'CppHashLocLineNo' to silence this warning
>>  unsigned CppHashLocLineNo;
>>   ^
>>= 0
>> /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2155:71: 
>> warning: variable 'LineNo' is
>> uninitialized when used here [-Wuninitialized]
>>  SMDiagnostic NewDiag(*Diag.getSourceMgr(), Diag.getLoc(), Filename, LineNo,
>>  ^~
>> /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2152:13: 
>> note: initialize the variable
>> 'LineNo' to silence this warning
>>  int LineNo =
>>^
>> = 0
>> clang-4.0: error: unable to execute command: Segmentation fault (core dumped)
>> clang-4.0: error: clang frontend command failed due to signal (use -v to see 
>> invocation)
>> clang version 4.0.0 (tags/RELEASE_400/rc1)
>> Target: i386-unknown-freebsd10.3
>> Thread model: posix
>> InstalledDir: 
>> /home/dim/llvm-4.0.0/rc1/Phase1/Release/llvmCore-4.0.0-rc1.install/usr/local/bin
>> clang-4.0: note: diagnostic msg: PLEASE submit a bug report to 
>> http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, 
>> and associated run script.
>> clang-4.0: note: diagnostic msg:
>> 
>> 
>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
>> Preprocessed source(s) and associated run script(s) are located at:
>> clang-4.0: note: diagnostic msg: /home/dim/tmp/AsmParser-c3ca7e.cpp
>> clang-4.0: note: diagnostic msg: /home/dim/tmp/AsmParser-c3ca7e.sh
>> clang-4.0: note: diagnostic msg:
>> 
>> 
>> gmake[2]: *** [lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/build.make:87: 
>> lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o] Error 254
>> 
>> I thought this might be because r292133 was not merged yet, but I was wrong 
>> about that, it *is* merged.
>> 
>> So I will have to investigate why it crashes here.
> 
> Is this PR31692 that you filed today?

Yes.  It turned out to be an assertion '(it != OpaqueRValues.end() &&
"no mapping for opaque value!"), function getOpaqueRValueMapping', but
Phase2 is built without assertions, so it segfaulted instead.

-Dimitry



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

Re: [lldb-dev] [cfe-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

2017-01-19 Thread Diana Picus via lldb-dev 
Hi,

Looks good on AArch64:
c6cc242dc3551c8465ba054e87e4d51df824aa17
clang+llvm-4.0.0-rc1-aarch64-linux-gnu.tar.xz

Regards,
Diana

On 18 January 2017 at 17:45, Hans Wennborg via cfe-dev
 wrote:
> Dear testers,
>
> 4.0.0-rc1 was just tagged from the branch, with r292377.
>
> There are still open merge requests and bugs, but I'd like to get the
> testing started to see what issues come up.
>
> Please build, test, and upload binaries to the sftp. Let me know how
> it goes. I'll upload source, docs, and your binaries to the web site
> once their ready.
>
> Thanks,
> Hans
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

2017-01-19 Thread Eugene Birukov via lldb-dev 
Hi,


I have a Linux core dump that causes LLDB 3.9 on Linux crash. I would greatly 
appreciate any advise how to deal with the problem or what else I should look 
at.


The core dump was produced by GDB and GDB itself opens it without problems.


So, during loading the core we call 
DynamicLoaderPOSIXDYLD::LoadAllCurrentModules() which enumerates all the 
modules and does some processing. In the course of actions, it calls the  
ObjectFileELF::GetSectionHeaderInfo() for each module. This guy tries to load 
section headers and read string table. Well, it gets some garbage in the 
section header struct and tries to allocate 1.5TB memory which causes operator 
new throw.


So, why we get garbage?


The module in question is libc++abi.so.1:


521 ModuleSP module_sp = LoadModuleAtAddress(I->file_spec, 
I->link_addr, I->base_addr, true);

(gdb) p I->file_spec

$95 = {

  m_directory = {

m_string = 0x829a58 "... redacted ..."

  },

  m_filename = {

m_string = 0x7cc9e8 "libc++abi.so.1"

  },

  m_is_resolved = false,

  m_syntax = lldb_private::FileSpec::ePathSyntaxPosix

}


The module header lives at address 0x7f699a27  and looks OK. The section 
headers are supposed to be at offset 2495600 == 0x261470


$96 = (const elf::ELFHeader &) @0x953a78: {

  e_ident = "\177ELF\002\001\001\000\000\000\000\000\000\000\000",

  e_entry = 33392,

  e_phoff = 64,

  e_shoff = 2495600,

  e_flags = 0,

  e_version = 1,

  e_type = 3,

  e_machine = 62,

  e_ehsize = 64,

  e_phentsize = 56,

  e_phnum = 7,

  e_shentsize = 64,

  e_shnum = 38,

  e_shstrndx = 35

}


LLDB tries to read the section headers from that address 0x7f699a27  + 
0x261470 == 0x7F699A4D1470 without a second thought, but this number is a lie. 
The /proc//maps file shows it as belonging to something else:


7f699a27-7f699a2ba000 r-xp  fd:02 537796791  
.../libc++abi.so.1
7f699a2ba000-7f699a4b9000 ---p 0004a000 fd:02 537796791  
.../libc++abi.so.1
7f699a4b9000-7f699a4bb000 r--p 00049000 fd:02 537796791  
.../libc++abi.so.1
7f699a4bb000-7f699a4bc000 rw-p 0004b000 fd:02 537796791  
.../libc++abi.so.1
7f699a4bc000-7f699a52 r-xp  fd:00 202587414  
/usr/lib64/libssl.so.1.0.1e
7f699a52-7f699a71f000 ---p 00064000 fd:00 202587414  
/usr/lib64/libssl.so.1.0.1e
7f699a71f000-7f699a723000 r--p 00063000 fd:00 202587414  
/usr/lib64/libssl.so.1.0.1e
7f699a723000-7f699a72a000 rw-p 00067000 fd:00 202587414  
/usr/lib64/libssl.so.1.0.1e

I.e. LLDB should verify the module boundaries and fall back to some other plan 
if the memory is not there.


Now the question is - where would be the right place to do the fix?


Thanks,

Eugene








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

Re: [lldb-dev] [Release-testers] [cfe-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

2017-01-19 Thread Renato Golin via lldb-dev 
On 19 January 2017 at 17:43, Diana Picus via Release-testers
 wrote:
> Looks good on AArch64:
> c6cc242dc3551c8465ba054e87e4d51df824aa17
> clang+llvm-4.0.0-rc1-aarch64-linux-gnu.tar.xz

All good on ARM's side, too:

38e34694bb2ddd5178f48c2bef0aef65cc17b378
clang+llvm-4.0.0-rc1-armv7a-linux-gnueabihf.tar.xz

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

[lldb-dev] [Bug 31699] New: [Windows] LLDB crashes when launched with a startup script on the command line.

2017-01-19 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=31699

Bug ID: 31699
   Summary: [Windows] LLDB crashes when launched with a startup
script on the command line.
   Product: lldb
   Version: 4.0
  Hardware: PC
OS: Windows XP
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: vadi...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

- Install LLVM for Windows snapshot build from http://llvm.org/build (SVN
r291454, built on 9 January 2017 at the time of filing this).
- Launch LLDB: lldb -O "p 42".
- LLDB crashes.

I've tracked the cause down to snapshot builds being built with a statically
linked CRT (-DLLVM_USE_CRT_RELEASE=MT).  When a startup script is given on the
command line, lldb.exe creates a pipe, writes the script into the write end,
wraps a stdio file around the read end, and gives the resulting FILE* to
SBDebugger::SetInputFileHandle().  Unfortunately, since SBDebugger lives in
liblldb.dll, with its own copy of the CRT, that handle is not valid there. 
Later, it tries to read from that handle, and... boom.

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

Re: [lldb-dev] [llvm-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

2017-01-19 Thread Mehdi Amini via lldb-dev 
Just pushed Darwin:

d93fca2905fece5b5392a0025c2f5f09f044a17c  
clang+llvm-4.0.0-rc1-x86_64-apple-darwin.tar.xz

— 
Mehdi

> On Jan 18, 2017, at 7:45 AM, Hans Wennborg via llvm-dev 
>  wrote:
> 
> Dear testers,
> 
> 4.0.0-rc1 was just tagged from the branch, with r292377.
> 
> There are still open merge requests and bugs, but I'd like to get the
> testing started to see what issues come up.
> 
> Please build, test, and upload binaries to the sftp. Let me know how
> it goes. I'll upload source, docs, and your binaries to the web site
> once their ready.
> 
> Thanks,
> Hans
> ___
> 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

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-19 Thread Vadim Chugunov via lldb-dev 
I don't know an easy way to accomplish that.  While app-local deployment is
now supported, the set of deployed dlls depends on the host OS version
(according to this
).
  I've opened a bug  for now.

On Thu, Jan 12, 2017 at 4:12 PM, Reid Kleckner  wrote:

> On Thu, Jan 12, 2017 at 10:18 AM, Vadim Chugunov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I was referring to this: https://support.microsof
>> t.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows.
>> Granted, it was probably marked as non-critical, so some users may have
>> skipped it.
>>
>> >  One of the redist options is to include an MSU in your installer that
>> tells Windows Update to add UCRT to the list of components it updates
>>
>> We should figure out how to do that.
>>
>> But meanwhile, do people here agree that LLVM should be built with the
>> /MD flag?
>>
>
> We should do whatever makes it really simple to add clang to path and run
> it without any DLL conflicts. If it's easy to copy the vc runtime DLLs into
> our package in a compatible way, great, so long as users can unzip the
> package and run it from whereever it is without installing any
> dependencies. Static linking just happens to be the easiest way to achieve
> that.
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev