Re: [lldb-dev] Prebuilt binary for Windows

[Reid Kleckner via lldb-dev]

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

Re: [lldb-dev] Prebuilt binary for Windows

[Nico Weber via lldb-dev]

On Thu, Jan 12, 2017 at 1:18 PM, Vadim Chugunov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I was referring to this: https://support.microsoft.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?
>

Like Reid said above, clang should statically link the CRT.


>
>
> On Thu, Jan 12, 2017 at 9:36 AM, Adrian McCarthy 
> wrote:
>
>> >  [UCRT] had been pushed to Vista, 7 and 8 via Windows Update
>>
>> I didn't think that was true in general.  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.  So some Vista, 7, and 8 users may have
>> received it via Windows Update, but probably not all.
>>
>> That's what all the deployment articles seem to suggest (assuming I've
>> understood them correctly).  I suppose they may have decided to ship UCRT
>> to pre-Windows 10 users anyway, but I haven't come across anything that
>> says that.
>>
>> On Wed, Jan 11, 2017 at 6:48 PM, Vadim Chugunov 
>> wrote:
>>
>>>
>>>
>>> On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner 
>>> wrote:
>>>
 Ahh, that would make sense as well, since LLDB links against liblldb as
 a dll.  Don't see a good solution to this short of forcing dynamic linking.
  liblldb has to be a dll because it needs to be visible to python as an
 extension module.  And if it's a dll and uses static linking, then we would
 have to require that lldb.exe not pass file handles across the dll
 boundary.  If that's easy then great, but I suspect it probably isn't.

 Honestly dynamic linking was created to solve exactly these kinds of
 problems.  Yes there's the redist issue if on Windows < 10, but it seems
 like a small price to pay for something that doesn't have weird subtle
 bugs.  And as time goes on, more and more people will be on windows 10
 anyway.

 Does the redistributable issue present a challenge for your use case?

>>>
>>> There are actually two part of the MSVC runtime: the Universal C Runtime
>>> (UCRT) and the compiler-specific, VCRUNTIME140.   The former is widely
>>> available (comes with Windows 10, and had been pushed to Vista, 7 and 8 via
>>> Windows Update).  The latter is tied to the compiler version and must still
>>> be redistributed with programs.   Ideally, LLDB would use dynamic UCRT +
>>> static VCRUNTIMExx.  Unfortunately this doesn't seem to be a supported
>>> configuration (discussion of this issue in Python bug tracker
>>> ).   Looks like Python folks opted
>>> for shipping VCRUNTIME140.DLL in their install directory.
>>>
>>>
>>
>
> ___
> 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

Re: [lldb-dev] Prebuilt binary for Windows

[Vadim Chugunov via lldb-dev]

I was referring to this:
https://support.microsoft.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?


On Thu, Jan 12, 2017 at 9:36 AM, Adrian McCarthy 
wrote:

> >  [UCRT] had been pushed to Vista, 7 and 8 via Windows Update
>
> I didn't think that was true in general.  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.  So some Vista, 7, and 8 users may have
> received it via Windows Update, but probably not all.
>
> That's what all the deployment articles seem to suggest (assuming I've
> understood them correctly).  I suppose they may have decided to ship UCRT
> to pre-Windows 10 users anyway, but I haven't come across anything that
> says that.
>
> On Wed, Jan 11, 2017 at 6:48 PM, Vadim Chugunov  wrote:
>
>>
>>
>> On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner 
>> wrote:
>>
>>> Ahh, that would make sense as well, since LLDB links against liblldb as
>>> a dll.  Don't see a good solution to this short of forcing dynamic linking.
>>>  liblldb has to be a dll because it needs to be visible to python as an
>>> extension module.  And if it's a dll and uses static linking, then we would
>>> have to require that lldb.exe not pass file handles across the dll
>>> boundary.  If that's easy then great, but I suspect it probably isn't.
>>>
>>> Honestly dynamic linking was created to solve exactly these kinds of
>>> problems.  Yes there's the redist issue if on Windows < 10, but it seems
>>> like a small price to pay for something that doesn't have weird subtle
>>> bugs.  And as time goes on, more and more people will be on windows 10
>>> anyway.
>>>
>>> Does the redistributable issue present a challenge for your use case?
>>>
>>
>> There are actually two part of the MSVC runtime: the Universal C Runtime
>> (UCRT) and the compiler-specific, VCRUNTIME140.   The former is widely
>> available (comes with Windows 10, and had been pushed to Vista, 7 and 8 via
>> Windows Update).  The latter is tied to the compiler version and must still
>> be redistributed with programs.   Ideally, LLDB would use dynamic UCRT +
>> static VCRUNTIMExx.  Unfortunately this doesn't seem to be a supported
>> configuration (discussion of this issue in Python bug tracker
>> ).   Looks like Python folks opted
>> for shipping VCRUNTIME140.DLL in their install directory.
>>
>>
>
___
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

[Adrian McCarthy via lldb-dev]

>  [UCRT] had been pushed to Vista, 7 and 8 via Windows Update

I didn't think that was true in general.  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.  So some Vista, 7, and 8 users may have
received it via Windows Update, but probably not all.

That's what all the deployment articles seem to suggest (assuming I've
understood them correctly).  I suppose they may have decided to ship UCRT
to pre-Windows 10 users anyway, but I haven't come across anything that
says that.

On Wed, Jan 11, 2017 at 6:48 PM, Vadim Chugunov  wrote:

>
>
> On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner 
> wrote:
>
>> Ahh, that would make sense as well, since LLDB links against liblldb as a
>> dll.  Don't see a good solution to this short of forcing dynamic linking.
>>  liblldb has to be a dll because it needs to be visible to python as an
>> extension module.  And if it's a dll and uses static linking, then we would
>> have to require that lldb.exe not pass file handles across the dll
>> boundary.  If that's easy then great, but I suspect it probably isn't.
>>
>> Honestly dynamic linking was created to solve exactly these kinds of
>> problems.  Yes there's the redist issue if on Windows < 10, but it seems
>> like a small price to pay for something that doesn't have weird subtle
>> bugs.  And as time goes on, more and more people will be on windows 10
>> anyway.
>>
>> Does the redistributable issue present a challenge for your use case?
>>
>
> There are actually two part of the MSVC runtime: the Universal C Runtime
> (UCRT) and the compiler-specific, VCRUNTIME140.   The former is widely
> available (comes with Windows 10, and had been pushed to Vista, 7 and 8 via
> Windows Update).  The latter is tied to the compiler version and must still
> be redistributed with programs.   Ideally, LLDB would use dynamic UCRT +
> static VCRUNTIMExx.  Unfortunately this doesn't seem to be a supported
> configuration (discussion of this issue in Python bug tracker
> ).   Looks like Python folks opted
> for shipping VCRUNTIME140.DLL in their install directory.
>
>
___
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

[Ted Woodward via lldb-dev]

The compiler redistributable is also widely available:

 

https://www.microsoft.com/en-us/download/details.aspx?id=48145

 

The python 3.5 dll would still use the runtime dll; lldb should do the same. 
I’ve had crashes in the past because lldb and python used different runtimes.

 

 

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Vadim 
Chugunov via lldb-dev
Sent: Wednesday, January 11, 2017 8:49 PM
To: Zachary Turner 
Cc: LLDB 
Subject: Re: [lldb-dev] Prebuilt binary for Windows

 

 

 

On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner  > wrote:

Ahh, that would make sense as well, since LLDB links against liblldb as a dll.  
Don't see a good solution to this short of forcing dynamic linking.  liblldb 
has to be a dll because it needs to be visible to python as an extension 
module.  And if it's a dll and uses static linking, then we would have to 
require that lldb.exe not pass file handles across the dll boundary.  If that's 
easy then great, but I suspect it probably isn't.  

 

Honestly dynamic linking was created to solve exactly these kinds of problems.  
Yes there's the redist issue if on Windows < 10, but it seems like a small 
price to pay for something that doesn't have weird subtle bugs.  And as time 
goes on, more and more people will be on windows 10 anyway.

 

Does the redistributable issue present a challenge for your use case?

 

There are actually two part of the MSVC runtime: the Universal C Runtime (UCRT) 
and the compiler-specific, VCRUNTIME140.   The former is widely available 
(comes with Windows 10, and had been pushed to Vista, 7 and 8 via Windows 
Update).  The latter is tied to the compiler version and must still be 
redistributed with programs.   Ideally, LLDB would use dynamic UCRT + static 
VCRUNTIMExx.  Unfortunately this doesn't seem to be a supported configuration 
(discussion of this issue in Python bug tracker 
 ).   Looks like Python folks opted for 
shipping VCRUNTIME140.DLL in their install directory.

 

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

Re: [lldb-dev] LLDB failed to locate source when dwarf symbols are inside compile unit on Linux

[Tamas Berghammer via lldb-dev]

Hi Jeffrey,

For the source code locating issue based on your info my guess is that LLDB
doesn't able to resolve the relative file name path specified in your
symbol files to the absolute path required to load the file from disk. Can
you try running "target modules dump line-table " where the file
name is just the name of the file without any path? If the problem is what
I am guessing then you should see an output like this (note the relative
path).
(lldb) target modules dump line-table s.cpp
Line table for ./foo/s.cpp in `a.out
0x00400a0d: ./foo/s.cpp:3
0x00400a1a: ./foo/s.cpp:4
0x00400a58: ./foo/s.cpp:4
0x00400a64: ./foo/s.cpp:5
0x00400a93: ./foo/s.cpp:6
0x00400a9e: ./foo/s.cpp:6
...

The above problem can be worked around either by running LLDB with a
current working directory where the file path displayed by "target modules
dump line-table" is relative to or setting up a directory remapping for
that path using "settings set target.source-map ./ ".

Tamas

On Mon, Jan 9, 2017 at 11:55 PM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> In ELF files if there is a section named “.gnu_debuglink” it will contain
> a path to the external debug file. Dump this section and see what it
> contains. This section contains a null terminated C string as the path
> followed by a 4 byte aligned 32 bit integer which is a file CRC. Check to
> see the path is relative.
>
> I am guessing this is your problem.
>
> Greg
>
>
> On Jan 9, 2017, at 3:42 PM, Jeffrey Tan  wrote:
>
> Hey Greg, I just confirmed this with our build team. I seem to have
> misunderstood the location of debug symbol. It is actually not inside each
> individual object file but:
> The debug info in dev mode sits in the .debug_* sections of the shared
> libraries (we don't use debug fission).
> One potential complicating factor is that we relativize the 
> DW_AT_comp_dirattributes
> in the DWARF info, so that it's almost always just a long reference to the
> current working directory (e.g. .///).
>
> I do not know why this(symbol in shared library) would cause the bug
> though.
>
> Jeffrey
>
> On Mon, Jan 9, 2017 at 1:57 PM, Greg Clayton  wrote:
>
> Comments below.
>
> On Jan 9, 2017, at 1:10 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi,
>
> O ur company is using Buck(https://buckbuild.com/) to build internal
> service. Recently the build team made a change in buck to not merge dwarf
> symbols from each object file into final binary so debugger needs to read
> source/symbol table from compilation unit itself.
>
>
> How are debug symbols expected to be found? Is fission being used where
> the DWARF for each compile unit is in .dwo files and the main executable
> has skeleton DWARF? I will skip all other questions until we know more
> about how and where the DWARF is.
>
> Greg Clayton
>
>
>
> ___
> 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