Re: [lldb-dev] logging in lldb

[Pavel Labath via lldb-dev]

Happy new year everyone. :)

I have refreshed the implementation at
 with something more polished. I
consider this almost-ready, I just need feedback on a couple of
details:

- log->Warning/Debug/Error/Verbose: Currently we have a large number
of printf-style logging functions, which are very rarely used (and all
they do is prefix the log line with some string), and only one
formatv-style. It would be easy to add LLDB_WARN, LLDB_ERR, etc.
macros, so that these usages can be ported to the formatv-style.
However, I am not sure whether that's really necessary. One of the
goals of this process could be to standardize on one function. I would
prefer to keep just one log function, but I could be easily convinced
otherwise. For reference, these are the current approximate usages of
the logging functions (as determined by grep)
log->Error: 38 (mostly in ProcessWindows)
log->Warning: 25
log->Debug: 10 (mostly ClangExpressionParser)
log->Verbose: 6 (only ProcessWindows)
log->Printf: 2884

- ProcessWindowsLog: I am not going to go on a reformatting spree to
change all logging statements, but I would still like to change remove
the logging macros that windows log introduced, since they are very
custom, and I'd like to keep the number of logging syntaxes below 3
:). Zachary, Adrian, is that OK with you?



On 16 December 2016 at 20:15, Jim Ingham  wrote:
> Yeah, I’m with Jason.  I don’t find the current state of things hard to read 
> or work with.
>
> The proposed solutions seem a little uglier to me.  I try to avoid macros, to 
> me it makes it look like the code is shouting at you, giving the log lines 
> more prominence then they deserve in the overall flow of the code.  And all 
> upper case is harder to read.  If accumulating the log involves substantial 
> code and the code is all in macros it won’t be debuggable, which is a minor 
> shame.  But it’s not a huge deal since you can move the the code out of the 
> log statement temporarily if you need to debug it.

As it stands now, you'll still be able to write if(log) blocks. I
would also recommend this style for consideration:
LLDB_LOG(log, "current complex state is: {0}", GetCurrentComplexState());
- it does not interfere with the flow of the containing function, as
it is succinct, and you can still step through the complex function.

>
> I don’t see the need to work on this, but if it bugs you and you have the 
> time to do it, the moieties weigh evenly enough that I can’t see a reason to 
> object.

I must confess have a bit of an ulterior motive for doing this. :) My
goal is to start working on the modularization of the codebase. But I
don't want it to be just mindless moving of code around. I want to
spend some time considering the design of each piece, which should
slow things down long enough for the moves to not be annoying, and
hopefully produce better components. I'll write more on that soon - I
don't want to derail this discussion with it.

And yeah, the current logging state has been bugging me for a long time. ;)

cheers,
pl
___
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

[Hans Wennborg via lldb-dev]

Great! Thanks for pushing this.

On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov  wrote:
> Yes, the new build works!
>
> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg  wrote:
>>
>> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
>> Please let me know if that works.
>>
>> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner 
>> wrote:
>> > It sounds like the solution to the problem is to downgrade SWIG on the
>> > build
>> > machine.  If it's using version 3.0.9 or higher, just use whatever the
>> > last
>> > version before that is.  3.0.8, for example.
>> >
>> > At least there's a good workaround in the interim (i.e. setting
>> > PYTHONPATH)
>> >
>> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg 
>> > wrote:
>> >>
>> >> I'll do another snapshot maybe next week or the week after. You can
>> >> also ping me if you want it sooner or later.
>> >>
>> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
>> >> fully understand the problem here, but if there's some way to work
>> >> around it and get lldb into good shape for the 4.0.0 installer, that
>> >> would be great.
>> >>
>> >> Thanks,
>> >> Hans
>> >>
>> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov 
>> >> wrote:
>> >> > This appears to be a SWIG bug:
>> >> > https://github.com/swig/swig/issues/769
>> >> >
>> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
>> >> > wrote:
>> >> >>
>> >> >> It worked!
>> >> >>
>> >> >> ...but not before I set PYTHONPATH=C:\Program Files
>> >> >> (x86)\LLVM\lib\site-packages\lldb
>> >> >> Without that, it couldn't find the _lldb module, so we are not quite
>> >> >> out
>> >> >> of the woods yet.
>> >> >>
>> >> >> When are you planning to make the next snapshot build?
>> >> >> Thanks!
>> >> >>
>> >> >>
>> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
>> >> >> wrote:
>> >> >>>
>> >> >>> Vadim, it looks like your change was committed in r291291, and I've
>> >> >>> built a new snapshot today which includes it. Can you give it a try
>> >> >>> and see if everything works?
>> >> >>>
>> >> >>> Cheers,
>> >> >>> Hans
>> >> >>>
>> >> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner
>> >> >>> 
>> >> >>> wrote:
>> >> >>> > I will commit it, in the meantime can you request commit access
>> >> >>> > so
>> >> >>> > that
>> >> >>> > any
>> >> >>> > future patches you can commit?
>> >> >>> >
>> >> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov 
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> Thanks!
>> >> >>> >>
>> >> >>> >> Would anyone be so kind to commit that?
>> >> >>> >>
>> >> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner
>> >> >>> >> 
>> >> >>> >> wrote:
>> >> >>> >>>
>> >> >>> >>> Sorry, a combination of national holidays and extended
>> >> >>> >>> vacations
>> >> >>> >>> happened
>> >> >>> >>> and this fell off my radar.  lgtm
>> >> >>> >>>
>> >> >>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov
>> >> >>> >>> 
>> >> >>> >>> wrote:
>> >> >>> 
>> >> >>>  Zachary,
>> >> >>>  Can you please take a look at that change?
>> >> >>>  (https://reviews.llvm.org/D27476)
>> >> >>> 
>> >> >>>  It'll be sad if another snapshot build gets published with
>> >> >>>  broken
>> >> >>>  lldb.
>> >> >>>  :(
>> >> >>> 
>> >> >>> 
>> >> >>>  On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov
>> >> >>>  
>> >> >>>  wrote:
>> >> >>> >
>> >> >>> > This seems to work: https://reviews.llvm.org/D27476
>> >> >>> >
>> >> >>> > On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg
>> >> >>> > 
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> The only thing needed to build the installer should be
>> >> >>> >> having
>> >> >>> >> NSIS
>> >> >>> >> installed and building the "package" target generated by
>> >> >>> >> CMake.
>> >> >>> >> The
>> >> >>> >> other prerequisites are mostly for building the visual
>> >> >>> >> studio
>> >> >>> >> clang-format plugin.
>> >> >>> >>
>> >> >>> >> Having said that, you don't even have to build the installer
>> >> >>> >> to
>> >> >>> >> see
>> >> >>> >> what goes in it. Just building the "install" target
>> >> >>> >> generated
>> >> >>> >> by
>> >> >>> >> CMake
>> >> >>> >> will install the same set of files.
>> >> >>> >>
>> >> >>> >> I'm not sure how LLDB's cmake files are organized, but in
>> >> >>> >> the
>> >> >>> >> end
>> >> >>> >> what's required is invoking the install() command:
>> >> >>> >> https://cmake.org/cmake/help/v3.0/command/install.html  In
>> >> >>> >> LLVM,
>> >> >>> >> this
>> >> >>> >> is done automatically by macros such as add_llvm_executale,
>> >> >>> >> etc.
>> >> >>> >>
>> >> >>> >> On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov
>> >> >>> >> 
>> >> >>> >> wrote:
>> >> >>> >> > Hi Hans,
>> >> >>> >> >
>> >> >>> >> > I'd love to help, but I don't have half the tools that
>> >> >>> >> > build_llvm_package.bat requires instal

Re: [lldb-dev] logging in lldb

[Zachary Turner via lldb-dev]

On Wed, Jan 11, 2017 at 6:59 AM Pavel Labath  wrote:

> Happy new year everyone. :)
>
> I have refreshed the implementation at
>  with something more polished. I
> consider this almost-ready, I just need feedback on a couple of
> details:
>
> - log->Warning/Debug/Error/Verbose: Currently we have a large number
> of printf-style logging functions, which are very rarely used (and all
> they do is prefix the log line with some string), and only one
> formatv-style. It would be easy to add LLDB_WARN, LLDB_ERR, etc.
> macros, so that these usages can be ported to the formatv-style.
> However, I am not sure whether that's really necessary. One of the
> goals of this process could be to standardize on one function. I would
> prefer to keep just one log function, but I could be easily convinced
> otherwise. For reference, these are the current approximate usages of
> the logging functions (as determined by grep)
> log->Error: 38 (mostly in ProcessWindows)
> log->Warning: 25
> log->Debug: 10 (mostly ClangExpressionParser)
> log->Verbose: 6 (only ProcessWindows)
> log->Printf: 2884
>
Yea, these are unnecessary and it would be great to get rid of them.


>
> - ProcessWindowsLog: I am not going to go on a reformatting spree to
> change all logging statements, but I would still like to change remove
> the logging macros that windows log introduced, since they are very
> custom, and I'd like to keep the number of logging syntaxes below 3
> :). Zachary, Adrian, is that OK with you?
>
Fine with me, they were only introduced as an alternative to the verbose if
(log) syntaxes.  If there's an alternative that also solves the problem and
we can adopt everywhere, then I'm all for it.


>
> I must confess have a bit of an ulterior motive for doing this. :) My
> goal is to start working on the modularization of the codebase. But I
> don't want it to be just mindless moving of code around. I want to
> spend some time considering the design of each piece, which should
> slow things down long enough for the moves to not be annoying, and
> hopefully produce better components. I'll write more on that soon - I
> don't want to derail this discussion with it.
>
I'd start with one support library which we document and write in stone
(perhaps even enforce in CMake) that it can have no other dependencies on
LLDB libraries.  Then start moving various common data structures and
classes over there.  Like you said, we should save the details for another
thread, but in any case i look forward to seeing some proposals :)
___
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]

Sorry, just found another problem: the installed lldb crashes when given a
script via the command line.  For example, `lldb -O "p 42"` dies with
exception 0xC409.

It didn't happen with the one I've build locally, so I started digging...
The difference seems to be that build_llvm_build_package.bat links CRT
statically (-DLLVM_USE_CRT_RELEASE=MT), whereas default is the dynamic CRT.

The crash kinda makes sense, because python35.dll links CRT dynamically, so
LLDB ends up with two copies of it in the process, which is known to cause
all sorts of trouble.

Not sure what to do about this one, - you probably wanted static CRT to
avoid having to install MSVC redistributable?


On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov  wrote:

> Yes, the new build works!
>
> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg  wrote:
>
>> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
>> Please let me know if that works.
>>
>> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner 
>> wrote:
>> > It sounds like the solution to the problem is to downgrade SWIG on the
>> build
>> > machine.  If it's using version 3.0.9 or higher, just use whatever the
>> last
>> > version before that is.  3.0.8, for example.
>> >
>> > At least there's a good workaround in the interim (i.e. setting
>> PYTHONPATH)
>> >
>> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg 
>> wrote:
>> >>
>> >> I'll do another snapshot maybe next week or the week after. You can
>> >> also ping me if you want it sooner or later.
>> >>
>> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
>> >> fully understand the problem here, but if there's some way to work
>> >> around it and get lldb into good shape for the 4.0.0 installer, that
>> >> would be great.
>> >>
>> >> Thanks,
>> >> Hans
>> >>
>> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov 
>> wrote:
>> >> > This appears to be a SWIG bug: https://github.com/swig/swig/i
>> ssues/769
>> >> >
>> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
>> >> > wrote:
>> >> >>
>> >> >> It worked!
>> >> >>
>> >> >> ...but not before I set PYTHONPATH=C:\Program Files
>> >> >> (x86)\LLVM\lib\site-packages\lldb
>> >> >> Without that, it couldn't find the _lldb module, so we are not quite
>> >> >> out
>> >> >> of the woods yet.
>> >> >>
>> >> >> When are you planning to make the next snapshot build?
>> >> >> Thanks!
>> >> >>
>> >> >>
>> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
>> >> >> wrote:
>> >> >>>
>> >> >>> Vadim, it looks like your change was committed in r291291, and I've
>> >> >>> built a new snapshot today which includes it. Can you give it a try
>> >> >>> and see if everything works?
>> >> >>>
>> >> >>> Cheers,
>> >> >>> Hans
>> >> >>>
>> >> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner <
>> ztur...@google.com>
>> >> >>> wrote:
>> >> >>> > I will commit it, in the meantime can you request commit access
>> so
>> >> >>> > that
>> >> >>> > any
>> >> >>> > future patches you can commit?
>> >> >>> >
>> >> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov > >
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> Thanks!
>> >> >>> >>
>> >> >>> >> Would anyone be so kind to commit that?
>> >> >>> >>
>> >> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner
>> >> >>> >> 
>> >> >>> >> wrote:
>> >> >>> >>>
>> >> >>> >>> Sorry, a combination of national holidays and extended
>> vacations
>> >> >>> >>> happened
>> >> >>> >>> and this fell off my radar.  lgtm
>> >> >>> >>>
>> >> >>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov <
>> vadi...@gmail.com>
>> >> >>> >>> wrote:
>> >> >>> 
>> >> >>>  Zachary,
>> >> >>>  Can you please take a look at that change?
>> >> >>>  (https://reviews.llvm.org/D27476)
>> >> >>> 
>> >> >>>  It'll be sad if another snapshot build gets published with
>> broken
>> >> >>>  lldb.
>> >> >>>  :(
>> >> >>> 
>> >> >>> 
>> >> >>>  On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov
>> >> >>>  
>> >> >>>  wrote:
>> >> >>> >
>> >> >>> > This seems to work: https://reviews.llvm.org/D27476
>> >> >>> >
>> >> >>> > On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg
>> >> >>> > 
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> The only thing needed to build the installer should be
>> having
>> >> >>> >> NSIS
>> >> >>> >> installed and building the "package" target generated by
>> CMake.
>> >> >>> >> The
>> >> >>> >> other prerequisites are mostly for building the visual
>> studio
>> >> >>> >> clang-format plugin.
>> >> >>> >>
>> >> >>> >> Having said that, you don't even have to build the
>> installer to
>> >> >>> >> see
>> >> >>> >> what goes in it. Just building the "install" target
>> generated
>> >> >>> >> by
>> >> >>> >> CMake
>> >> >>> >> will install the same set of files.
>> >> >>> >>
>> >> >>> >> I'm not sure how LLDB's cmake files are organized, but in
>> the
>> >> >>> >> end
>> >> >>> >> what's required is invoking

Re: [lldb-dev] Prebuilt binary for Windows

[Zachary Turner via lldb-dev]

Is static CRT even still supported / recommended when using the new
Universal CRT?  My understanding is the new UCRT is considered a core
windows component, so we don't ahve to distribute redistributables
anymore.  Maybe I'm wrong about this.

That said, I think we want dynamic regardless, otherwise we're back in the
same boat of user having to compile Python, which is the exact thing 3.5+
is supposed to solve.  We should just always use dynamic so the user
doesn't have to do anything and it just works.

On Wed, Jan 11, 2017 at 10:41 AM Vadim Chugunov  wrote:

> Sorry, just found another problem: the installed lldb crashes when given a
> script via the command line.  For example, `lldb -O "p 42"` dies with
> exception 0xC409.
>
> It didn't happen with the one I've build locally, so I started digging...
> The difference seems to be that build_llvm_build_package.bat links CRT
> statically (-DLLVM_USE_CRT_RELEASE=MT), whereas default is the dynamic CRT.
>
> The crash kinda makes sense, because python35.dll links CRT dynamically,
> so LLDB ends up with two copies of it in the process, which is known to
> cause all sorts of trouble.
>
> Not sure what to do about this one, - you probably wanted static CRT to
> avoid having to install MSVC redistributable?
>
>
> On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov  wrote:
>
> Yes, the new build works!
>
> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg  wrote:
>
> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
> Please let me know if that works.
>
> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner 
> wrote:
> > It sounds like the solution to the problem is to downgrade SWIG on the
> build
> > machine.  If it's using version 3.0.9 or higher, just use whatever the
> last
> > version before that is.  3.0.8, for example.
> >
> > At least there's a good workaround in the interim (i.e. setting
> PYTHONPATH)
> >
> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg 
> wrote:
> >>
> >> I'll do another snapshot maybe next week or the week after. You can
> >> also ping me if you want it sooner or later.
> >>
> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
> >> fully understand the problem here, but if there's some way to work
> >> around it and get lldb into good shape for the 4.0.0 installer, that
> >> would be great.
> >>
> >> Thanks,
> >> Hans
> >>
> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov 
> wrote:
> >> > This appears to be a SWIG bug:
> https://github.com/swig/swig/issues/769
> >> >
> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
> >> > wrote:
> >> >>
> >> >> It worked!
> >> >>
> >> >> ...but not before I set PYTHONPATH=C:\Program Files
> >> >> (x86)\LLVM\lib\site-packages\lldb
> >> >> Without that, it couldn't find the _lldb module, so we are not quite
> >> >> out
> >> >> of the woods yet.
> >> >>
> >> >> When are you planning to make the next snapshot build?
> >> >> Thanks!
> >> >>
> >> >>
> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
> >> >> wrote:
> >> >>>
> >> >>> Vadim, it looks like your change was committed in r291291, and I've
> >> >>> built a new snapshot today which includes it. Can you give it a try
> >> >>> and see if everything works?
> >> >>>
> >> >>> Cheers,
> >> >>> Hans
> >> >>>
> >> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner  >
> >> >>> wrote:
> >> >>> > I will commit it, in the meantime can you request commit access so
> >> >>> > that
> >> >>> > any
> >> >>> > future patches you can commit?
> >> >>> >
> >> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov 
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> Thanks!
> >> >>> >>
> >> >>> >> Would anyone be so kind to commit that?
> >> >>> >>
> >> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner
> >> >>> >> 
> >> >>> >> wrote:
> >> >>> >>>
> >> >>> >>> Sorry, a combination of national holidays and extended vacations
> >> >>> >>> happened
> >> >>> >>> and this fell off my radar.  lgtm
> >> >>> >>>
> >> >>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov <
> vadi...@gmail.com>
> >> >>> >>> wrote:
> >> >>> 
> >> >>>  Zachary,
> >> >>>  Can you please take a look at that change?
> >> >>>  (https://reviews.llvm.org/D27476)
> >> >>> 
> >> >>>  It'll be sad if another snapshot build gets published with
> broken
> >> >>>  lldb.
> >> >>>  :(
> >> >>> 
> >> >>> 
> >> >>>  On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov
> >> >>>  
> >> >>>  wrote:
> >> >>> >
> >> >>> > This seems to work: https://reviews.llvm.org/D27476
> >> >>> >
> >> >>> > On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg
> >> >>> > 
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> The only thing needed to build the installer should be having
> >> >>> >> NSIS
> >> >>> >> installed and building the "package" target generated by
> CMake.
> >> >>> >> The
> >> >>> >> other prerequisites are mostly for building the visual studio
> >> >>> >> clang-format plugin.
> >> >>> >>

Re: [lldb-dev] Prebuilt binary for Windows

[Reid Kleckner via lldb-dev]

The purpose of linking the CRT statically was to ensure that clang can run
on systems that don't have the CRT already installed from some other app or
by VS itself. As long as that is preserved, feel free to do whatever you
need.

I think we still want to link vcruntime140 statically and the C++ runtime
statically, for example.

On Wed, Jan 11, 2017 at 10:45 AM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Is static CRT even still supported / recommended when using the new
> Universal CRT?  My understanding is the new UCRT is considered a core
> windows component, so we don't ahve to distribute redistributables
> anymore.  Maybe I'm wrong about this.
>
> That said, I think we want dynamic regardless, otherwise we're back in the
> same boat of user having to compile Python, which is the exact thing 3.5+
> is supposed to solve.  We should just always use dynamic so the user
> doesn't have to do anything and it just works.
>
> On Wed, Jan 11, 2017 at 10:41 AM Vadim Chugunov  wrote:
>
>> Sorry, just found another problem: the installed lldb crashes when given
>> a script via the command line.  For example, `lldb -O "p 42"` dies with
>> exception 0xC409.
>>
>> It didn't happen with the one I've build locally, so I started digging...
>> The difference seems to be that build_llvm_build_package.bat links CRT
>> statically (-DLLVM_USE_CRT_RELEASE=MT), whereas default is the dynamic CRT.
>>
>> The crash kinda makes sense, because python35.dll links CRT dynamically,
>> so LLDB ends up with two copies of it in the process, which is known to
>> cause all sorts of trouble.
>>
>> Not sure what to do about this one, - you probably wanted static CRT to
>> avoid having to install MSVC redistributable?
>>
>>
>> On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov 
>> wrote:
>>
>> Yes, the new build works!
>>
>> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg  wrote:
>>
>> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
>> Please let me know if that works.
>>
>> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner 
>> wrote:
>> > It sounds like the solution to the problem is to downgrade SWIG on the
>> build
>> > machine.  If it's using version 3.0.9 or higher, just use whatever the
>> last
>> > version before that is.  3.0.8, for example.
>> >
>> > At least there's a good workaround in the interim (i.e. setting
>> PYTHONPATH)
>> >
>> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg 
>> wrote:
>> >>
>> >> I'll do another snapshot maybe next week or the week after. You can
>> >> also ping me if you want it sooner or later.
>> >>
>> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
>> >> fully understand the problem here, but if there's some way to work
>> >> around it and get lldb into good shape for the 4.0.0 installer, that
>> >> would be great.
>> >>
>> >> Thanks,
>> >> Hans
>> >>
>> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov 
>> wrote:
>> >> > This appears to be a SWIG bug: https://github.com/swig/swig/
>> issues/769
>> >> >
>> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
>> >> > wrote:
>> >> >>
>> >> >> It worked!
>> >> >>
>> >> >> ...but not before I set PYTHONPATH=C:\Program Files
>> >> >> (x86)\LLVM\lib\site-packages\lldb
>> >> >> Without that, it couldn't find the _lldb module, so we are not quite
>> >> >> out
>> >> >> of the woods yet.
>> >> >>
>> >> >> When are you planning to make the next snapshot build?
>> >> >> Thanks!
>> >> >>
>> >> >>
>> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
>> >> >> wrote:
>> >> >>>
>> >> >>> Vadim, it looks like your change was committed in r291291, and I've
>> >> >>> built a new snapshot today which includes it. Can you give it a try
>> >> >>> and see if everything works?
>> >> >>>
>> >> >>> Cheers,
>> >> >>> Hans
>> >> >>>
>> >> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner <
>> ztur...@google.com>
>> >> >>> wrote:
>> >> >>> > I will commit it, in the meantime can you request commit access
>> so
>> >> >>> > that
>> >> >>> > any
>> >> >>> > future patches you can commit?
>> >> >>> >
>> >> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov > >
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> Thanks!
>> >> >>> >>
>> >> >>> >> Would anyone be so kind to commit that?
>> >> >>> >>
>> >> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner
>> >> >>> >> 
>> >> >>> >> wrote:
>> >> >>> >>>
>> >> >>> >>> Sorry, a combination of national holidays and extended
>> vacations
>> >> >>> >>> happened
>> >> >>> >>> and this fell off my radar.  lgtm
>> >> >>> >>>
>> >> >>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov <
>> vadi...@gmail.com>
>> >> >>> >>> wrote:
>> >> >>> 
>> >> >>>  Zachary,
>> >> >>>  Can you please take a look at that change?
>> >> >>>  (https://reviews.llvm.org/D27476)
>> >> >>> 
>> >> >>>  It'll be sad if another snapshot build gets published with
>> broken
>> >> >>>  lldb.
>> >> >>>  :(
>> >> >>> 
>> >> >>> 
>> >> >>>  On Tue, Dec 6, 2016 at 11:54

Re: [lldb-dev] logging in lldb

[Adrian McCarthy via lldb-dev]

On Wed, Jan 11, 2017 at 10:38 AM, Zachary Turner  wrote:

>
>
> On Wed, Jan 11, 2017 at 6:59 AM Pavel Labath  wrote:
>
>> Happy new year everyone. :)
>>
>> I have refreshed the implementation at
>>  with something more polished. I
>> consider this almost-ready, I just need feedback on a couple of
>> details:
>>
>> - log->Warning/Debug/Error/Verbose: Currently we have a large number
>> of printf-style logging functions, which are very rarely used (and all
>> they do is prefix the log line with some string), and only one
>> formatv-style. It would be easy to add LLDB_WARN, LLDB_ERR, etc.
>> macros, so that these usages can be ported to the formatv-style.
>> However, I am not sure whether that's really necessary. One of the
>> goals of this process could be to standardize on one function. I would
>> prefer to keep just one log function, but I could be easily convinced
>> otherwise. For reference, these are the current approximate usages of
>> the logging functions (as determined by grep)
>> log->Error: 38 (mostly in ProcessWindows)
>> log->Warning: 25
>> log->Debug: 10 (mostly ClangExpressionParser)
>> log->Verbose: 6 (only ProcessWindows)
>> log->Printf: 2884
>>
> Yea, these are unnecessary and it would be great to get rid of them.
>
>
>>
>> - ProcessWindowsLog: I am not going to go on a reformatting spree to
>> change all logging statements, but I would still like to change remove
>> the logging macros that windows log introduced, since they are very
>> custom, and I'd like to keep the number of logging syntaxes below 3
>> :). Zachary, Adrian, is that OK with you?
>>
> Fine with me, they were only introduced as an alternative to the verbose
> if (log) syntaxes.  If there's an alternative that also solves the problem
> and we can adopt everywhere, then I'm all for it.
>

Fine with me as well.


>
>
>>
>> I must confess have a bit of an ulterior motive for doing this. :) My
>> goal is to start working on the modularization of the codebase. But I
>> don't want it to be just mindless moving of code around. I want to
>> spend some time considering the design of each piece, which should
>> slow things down long enough for the moves to not be annoying, and
>> hopefully produce better components. I'll write more on that soon - I
>> don't want to derail this discussion with it.
>>
> I'd start with one support library which we document and write in stone
> (perhaps even enforce in CMake) that it can have no other dependencies on
> LLDB libraries.  Then start moving various common data structures and
> classes over there.  Like you said, we should save the details for another
> thread, but in any case i look forward to seeing some proposals :)
>
___
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]

I was just reading up on this the other day.  Statically linking to the
Universal CRT (and related libraries) *is* supported though it's not
Microsoft's top recommendation.

Initially, they said they weren't going to support app-local deployment,
but they backed off on that, and it, too, is now supported.

Some details here:
https://blogs.msdn.microsoft.com/vcblog/2016/04/18/c-runtime-deployment-why-choosing-applocal/


On Wed, Jan 11, 2017 at 10:51 AM, Reid Kleckner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> The purpose of linking the CRT statically was to ensure that clang can run
> on systems that don't have the CRT already installed from some other app or
> by VS itself. As long as that is preserved, feel free to do whatever you
> need.
>
> I think we still want to link vcruntime140 statically and the C++ runtime
> statically, for example.
>
> On Wed, Jan 11, 2017 at 10:45 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Is static CRT even still supported / recommended when using the new
>> Universal CRT?  My understanding is the new UCRT is considered a core
>> windows component, so we don't ahve to distribute redistributables
>> anymore.  Maybe I'm wrong about this.
>>
>> That said, I think we want dynamic regardless, otherwise we're back in
>> the same boat of user having to compile Python, which is the exact thing
>> 3.5+ is supposed to solve.  We should just always use dynamic so the user
>> doesn't have to do anything and it just works.
>>
>> On Wed, Jan 11, 2017 at 10:41 AM Vadim Chugunov 
>> wrote:
>>
>>> Sorry, just found another problem: the installed lldb crashes when given
>>> a script via the command line.  For example, `lldb -O "p 42"` dies with
>>> exception 0xC409.
>>>
>>> It didn't happen with the one I've build locally, so I started
>>> digging... The difference seems to be that build_llvm_build_package.bat
>>> links CRT statically (-DLLVM_USE_CRT_RELEASE=MT), whereas default is the
>>> dynamic CRT.
>>> The crash kinda makes sense, because python35.dll links CRT dynamically,
>>> so LLDB ends up with two copies of it in the process, which is known to
>>> cause all sorts of trouble.
>>>
>>> Not sure what to do about this one, - you probably wanted static CRT to
>>> avoid having to install MSVC redistributable?
>>>
>>>
>>> On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov 
>>> wrote:
>>>
>>> Yes, the new build works!
>>>
>>> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg 
>>> wrote:
>>>
>>> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
>>> Please let me know if that works.
>>>
>>> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner 
>>> wrote:
>>> > It sounds like the solution to the problem is to downgrade SWIG on the
>>> build
>>> > machine.  If it's using version 3.0.9 or higher, just use whatever the
>>> last
>>> > version before that is.  3.0.8, for example.
>>> >
>>> > At least there's a good workaround in the interim (i.e. setting
>>> PYTHONPATH)
>>> >
>>> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg 
>>> wrote:
>>> >>
>>> >> I'll do another snapshot maybe next week or the week after. You can
>>> >> also ping me if you want it sooner or later.
>>> >>
>>> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
>>> >> fully understand the problem here, but if there's some way to work
>>> >> around it and get lldb into good shape for the 4.0.0 installer, that
>>> >> would be great.
>>> >>
>>> >> Thanks,
>>> >> Hans
>>> >>
>>> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov 
>>> wrote:
>>> >> > This appears to be a SWIG bug: https://github.com/swig/swig/i
>>> ssues/769
>>> >> >
>>> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
>>> >> > wrote:
>>> >> >>
>>> >> >> It worked!
>>> >> >>
>>> >> >> ...but not before I set PYTHONPATH=C:\Program Files
>>> >> >> (x86)\LLVM\lib\site-packages\lldb
>>> >> >> Without that, it couldn't find the _lldb module, so we are not
>>> quite
>>> >> >> out
>>> >> >> of the woods yet.
>>> >> >>
>>> >> >> When are you planning to make the next snapshot build?
>>> >> >> Thanks!
>>> >> >>
>>> >> >>
>>> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> Vadim, it looks like your change was committed in r291291, and
>>> I've
>>> >> >>> built a new snapshot today which includes it. Can you give it a
>>> try
>>> >> >>> and see if everything works?
>>> >> >>>
>>> >> >>> Cheers,
>>> >> >>> Hans
>>> >> >>>
>>> >> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner <
>>> ztur...@google.com>
>>> >> >>> wrote:
>>> >> >>> > I will commit it, in the meantime can you request commit access
>>> so
>>> >> >>> > that
>>> >> >>> > any
>>> >> >>> > future patches you can commit?
>>> >> >>> >
>>> >> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov <
>>> vadi...@gmail.com>
>>> >> >>> > wrote:
>>> >> >>> >>
>>> >> >>> >> Thanks!
>>> >> >>> >>
>>> >> >>> >> Would anyone be so kind to commit that?
>>> >> >>> >>
>>> >> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zach

Re: [lldb-dev] Prebuilt binary for Windows

[Zachary Turner via lldb-dev]

If we do that though, we still get 2 copies of the CRT.  One for python and
one for LLDB.  While I *think* there is a strong enough API boundary in how
the application and Python access each others' data structures that it
doesn't matter, I'm not 100% sure without further research.  It seems safer
to link dynamically unless there is a strong reason not to.

On Wed, Jan 11, 2017 at 12:41 PM Adrian McCarthy 
wrote:

> I was just reading up on this the other day.  Statically linking to the
> Universal CRT (and related libraries) *is* supported though it's not
> Microsoft's top recommendation.
>
> Initially, they said they weren't going to support app-local deployment,
> but they backed off on that, and it, too, is now supported.
>
> Some details here:
> https://blogs.msdn.microsoft.com/vcblog/2016/04/18/c-runtime-deployment-why-choosing-applocal/
>
>
> On Wed, Jan 11, 2017 at 10:51 AM, Reid Kleckner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> The purpose of linking the CRT statically was to ensure that clang can run
> on systems that don't have the CRT already installed from some other app or
> by VS itself. As long as that is preserved, feel free to do whatever you
> need.
>
> I think we still want to link vcruntime140 statically and the C++ runtime
> statically, for example.
>
> On Wed, Jan 11, 2017 at 10:45 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Is static CRT even still supported / recommended when using the new
> Universal CRT?  My understanding is the new UCRT is considered a core
> windows component, so we don't ahve to distribute redistributables
> anymore.  Maybe I'm wrong about this.
>
> That said, I think we want dynamic regardless, otherwise we're back in the
> same boat of user having to compile Python, which is the exact thing 3.5+
> is supposed to solve.  We should just always use dynamic so the user
> doesn't have to do anything and it just works.
>
> On Wed, Jan 11, 2017 at 10:41 AM Vadim Chugunov  wrote:
>
> Sorry, just found another problem: the installed lldb crashes when given a
> script via the command line.  For example, `lldb -O "p 42"` dies with
> exception 0xC409.
>
> It didn't happen with the one I've build locally, so I started digging...
> The difference seems to be that build_llvm_build_package.bat links CRT
> statically (-DLLVM_USE_CRT_RELEASE=MT), whereas default is the dynamic CRT.
>
> The crash kinda makes sense, because python35.dll links CRT dynamically,
> so LLDB ends up with two copies of it in the process, which is known to
> cause all sorts of trouble.
>
> Not sure what to do about this one, - you probably wanted static CRT to
> avoid having to install MSVC redistributable?
>
>
> On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov  wrote:
>
> Yes, the new build works!
>
> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg  wrote:
>
> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
> Please let me know if that works.
>
> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner 
> wrote:
> > It sounds like the solution to the problem is to downgrade SWIG on the
> build
> > machine.  If it's using version 3.0.9 or higher, just use whatever the
> last
> > version before that is.  3.0.8, for example.
> >
> > At least there's a good workaround in the interim (i.e. setting
> PYTHONPATH)
> >
> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg 
> wrote:
> >>
> >> I'll do another snapshot maybe next week or the week after. You can
> >> also ping me if you want it sooner or later.
> >>
> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
> >> fully understand the problem here, but if there's some way to work
> >> around it and get lldb into good shape for the 4.0.0 installer, that
> >> would be great.
> >>
> >> Thanks,
> >> Hans
> >>
> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov 
> wrote:
> >> > This appears to be a SWIG bug:
> https://github.com/swig/swig/issues/769
> >> >
> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
> >> > wrote:
> >> >>
> >> >> It worked!
> >> >>
> >> >> ...but not before I set PYTHONPATH=C:\Program Files
> >> >> (x86)\LLVM\lib\site-packages\lldb
> >> >> Without that, it couldn't find the _lldb module, so we are not quite
> >> >> out
> >> >> of the woods yet.
> >> >>
> >> >> When are you planning to make the next snapshot build?
> >> >> Thanks!
> >> >>
> >> >>
> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
> >> >> wrote:
> >> >>>
> >> >>> Vadim, it looks like your change was committed in r291291, and I've
> >> >>> built a new snapshot today which includes it. Can you give it a try
> >> >>> and see if everything works?
> >> >>>
> >> >>> Cheers,
> >> >>> Hans
> >> >>>
> >> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner  >
> >> >>> wrote:
> >> >>> > I will commit it, in the meantime can you request commit access so
> >> >>> > that
> >> >>> > any
> >> >>> > future patches you can commit?
> >> >>> >
> >> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov 
> >> >>> > 

Re: [lldb-dev] Prebuilt binary for Windows

[Adrian McCarthy via lldb-dev]

I agree that linking to them dynamically is safer, but then you get into
the deployment problem.  You do have to redistribute the DLLs for users
using anything less than Windows 10.

There are several options for doing that:  VCRedist, MSMs, MSUs, and
app-local deployment.  They each have drawbacks.

On Wed, Jan 11, 2017 at 1:00 PM, Zachary Turner  wrote:

> If we do that though, we still get 2 copies of the CRT.  One for python
> and one for LLDB.  While I *think* there is a strong enough API boundary in
> how the application and Python access each others' data structures that it
> doesn't matter, I'm not 100% sure without further research.  It seems safer
> to link dynamically unless there is a strong reason not to.
>
> On Wed, Jan 11, 2017 at 12:41 PM Adrian McCarthy 
> wrote:
>
>> I was just reading up on this the other day.  Statically linking to the
>> Universal CRT (and related libraries) *is* supported though it's not
>> Microsoft's top recommendation.
>>
>> Initially, they said they weren't going to support app-local deployment,
>> but they backed off on that, and it, too, is now supported.
>>
>> Some details here:  https://blogs.msdn.microsoft.com/vcblog/2016/04/18/c-
>> runtime-deployment-why-choosing-applocal/
>>
>>
>> On Wed, Jan 11, 2017 at 10:51 AM, Reid Kleckner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> The purpose of linking the CRT statically was to ensure that clang can
>> run on systems that don't have the CRT already installed from some other
>> app or by VS itself. As long as that is preserved, feel free to do whatever
>> you need.
>>
>> I think we still want to link vcruntime140 statically and the C++ runtime
>> statically, for example.
>>
>> On Wed, Jan 11, 2017 at 10:45 AM, Zachary Turner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> Is static CRT even still supported / recommended when using the new
>> Universal CRT?  My understanding is the new UCRT is considered a core
>> windows component, so we don't ahve to distribute redistributables
>> anymore.  Maybe I'm wrong about this.
>>
>> That said, I think we want dynamic regardless, otherwise we're back in
>> the same boat of user having to compile Python, which is the exact thing
>> 3.5+ is supposed to solve.  We should just always use dynamic so the user
>> doesn't have to do anything and it just works.
>>
>> On Wed, Jan 11, 2017 at 10:41 AM Vadim Chugunov 
>> wrote:
>>
>> Sorry, just found another problem: the installed lldb crashes when given
>> a script via the command line.  For example, `lldb -O "p 42"` dies with
>> exception 0xC409.
>>
>> It didn't happen with the one I've build locally, so I started digging...
>> The difference seems to be that build_llvm_build_package.bat links CRT
>> statically (-DLLVM_USE_CRT_RELEASE=MT), whereas default is the dynamic CRT.
>>
>> The crash kinda makes sense, because python35.dll links CRT dynamically,
>> so LLDB ends up with two copies of it in the process, which is known to
>> cause all sorts of trouble.
>>
>> Not sure what to do about this one, - you probably wanted static CRT to
>> avoid having to install MSVC redistributable?
>>
>>
>> On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov 
>> wrote:
>>
>> Yes, the new build works!
>>
>> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg  wrote:
>>
>> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
>> Please let me know if that works.
>>
>> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner 
>> wrote:
>> > It sounds like the solution to the problem is to downgrade SWIG on the
>> build
>> > machine.  If it's using version 3.0.9 or higher, just use whatever the
>> last
>> > version before that is.  3.0.8, for example.
>> >
>> > At least there's a good workaround in the interim (i.e. setting
>> PYTHONPATH)
>> >
>> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg 
>> wrote:
>> >>
>> >> I'll do another snapshot maybe next week or the week after. You can
>> >> also ping me if you want it sooner or later.
>> >>
>> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
>> >> fully understand the problem here, but if there's some way to work
>> >> around it and get lldb into good shape for the 4.0.0 installer, that
>> >> would be great.
>> >>
>> >> Thanks,
>> >> Hans
>> >>
>> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov 
>> wrote:
>> >> > This appears to be a SWIG bug: https://github.com/swig/swig/
>> issues/769
>> >> >
>> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
>> >> > wrote:
>> >> >>
>> >> >> It worked!
>> >> >>
>> >> >> ...but not before I set PYTHONPATH=C:\Program Files
>> >> >> (x86)\LLVM\lib\site-packages\lldb
>> >> >> Without that, it couldn't find the _lldb module, so we are not quite
>> >> >> out
>> >> >> of the woods yet.
>> >> >>
>> >> >> When are you planning to make the next snapshot build?
>> >> >> Thanks!
>> >> >>
>> >> >>
>> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
>> >> >> wrote:
>> >> >>>
>> >> >>> Vadim, it looks like your change was committ

Re: [lldb-dev] Prebuilt binary for Windows

[Vadim Chugunov via lldb-dev]

BTW, here's the call stack at the point of failure.   I don't see anything
Python-related in it, so maybe it's some other CRT interaction.

liblldb!_invoke_watson(wchar_t * expression = 0x "", wchar_t *
function_name = 0x "", wchar_t * file_name = 0x "",
unsigned int line_number = 0, unsigned int reserved = 0)+0xe
liblldb!_invalid_parameter(wchar_t * expression = , wchar_t * function_name = , wchar_t *
file_name = , unsigned int line_number = , unsigned int reserved = )+0x7a
liblldb!_invalid_parameter_noinfo(void)+0xc
liblldb!_read(int fh = 0n0, void * buffer = 0x05afbb50, unsigned int
buffer_size = 0x1000)+0x10a
liblldb!common_refill_and_read_nolock(class __crt_stdio_stream stream
= class __crt_stdio_stream)+0x9f
liblldb!_fgetc_nolock(struct _iobuf * public_stream = 0x05af9c58)+0x2d
liblldb!__crt_char_traits::getc_nolock+0x8
liblldb!common_fgets(char * string = 0x019cf41c "b", int count =
0n256, class __crt_stdio_stream stream = class __crt_stdio_stream)+0x81
liblldb!lldb_private::IOHandlerEditline::GetLine(class
std::basic_string,std::allocator > * line
= 0x019cf548 "", bool * interrupted = 0x019cf537)+0xd6
liblldb!lldb_private::IOHandlerEditline::Run(void)+0x11a
liblldb!lldb_private::Debugger::ExecuteIOHandlers(void)+0x35
liblldb!lldb_private::CommandInterpreter::RunCommandInterpreter(bool
auto_handle_events = true, bool spawn_thread = false, class
lldb_private::CommandInterpreterRunOptions * options = 0x05af9ca8)+0x7e
liblldb!lldb::SBDebugger::RunCommandInterpreter(bool auto_handle_events =
true, bool spawn_thread = false, class lldb::SBCommandInterpreterRunOptions
* options = 0x019cf604, int * num_errors = 0x019cf630, bool *
quit_requested = 0x019cf603, bool * stopped_for_crash = 0x019cf60a)+0x43
lldb!Driver::MainLoop(void)+0x639
lldb!wmain(int argc = 0n3, wchar_t ** wargv = 0x01b28c90)+0x249
lldb!invoke_main+0x1d
lldb!__scrt_common_main_seh(void)+0xff
KERNEL32!BaseThreadInitThunk+0x24
ntdll_76f3!__RtlUserThreadStart+0x2f
ntdll_76f3!_RtlUserThreadStart+0x1b

On Wed, Jan 11, 2017 at 1:10 PM, Adrian McCarthy via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I agree that linking to them dynamically is safer, but then you get into
> the deployment problem.  You do have to redistribute the DLLs for users
> using anything less than Windows 10.
>
> There are several options for doing that:  VCRedist, MSMs, MSUs, and
> app-local deployment.  They each have drawbacks.
>
> On Wed, Jan 11, 2017 at 1:00 PM, Zachary Turner 
> wrote:
>
>> If we do that though, we still get 2 copies of the CRT.  One for python
>> and one for LLDB.  While I *think* there is a strong enough API boundary in
>> how the application and Python access each others' data structures that it
>> doesn't matter, I'm not 100% sure without further research.  It seems safer
>> to link dynamically unless there is a strong reason not to.
>>
>> On Wed, Jan 11, 2017 at 12:41 PM Adrian McCarthy 
>> wrote:
>>
>>> I was just reading up on this the other day.  Statically linking to the
>>> Universal CRT (and related libraries) *is* supported though it's not
>>> Microsoft's top recommendation.
>>>
>>> Initially, they said they weren't going to support app-local deployment,
>>> but they backed off on that, and it, too, is now supported.
>>>
>>> Some details here:  https://blogs.msdn.microsoft.
>>> com/vcblog/2016/04/18/c-runtime-deployment-why-choosing-applocal/
>>>
>>>
>>> On Wed, Jan 11, 2017 at 10:51 AM, Reid Kleckner via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>> The purpose of linking the CRT statically was to ensure that clang can
>>> run on systems that don't have the CRT already installed from some other
>>> app or by VS itself. As long as that is preserved, feel free to do whatever
>>> you need.
>>>
>>> I think we still want to link vcruntime140 statically and the C++
>>> runtime statically, for example.
>>>
>>> On Wed, Jan 11, 2017 at 10:45 AM, Zachary Turner via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>> Is static CRT even still supported / recommended when using the new
>>> Universal CRT?  My understanding is the new UCRT is considered a core
>>> windows component, so we don't ahve to distribute redistributables
>>> anymore.  Maybe I'm wrong about this.
>>>
>>> That said, I think we want dynamic regardless, otherwise we're back in
>>> the same boat of user having to compile Python, which is the exact thing
>>> 3.5+ is supposed to solve.  We should just always use dynamic so the user
>>> doesn't have to do anything and it just works.
>>>
>>> On Wed, Jan 11, 2017 at 10:41 AM Vadim Chugunov 
>>> wrote:
>>>
>>> Sorry, just found another problem: the installed lldb crashes when given
>>> a script via the command line.  For example, `lldb -O "p 42"` dies with
>>> exception 0xC409.
>>>
>>> It didn't happen with the one I've build locally, so I started
>>> digging... The difference seems to be that build_llvm_build_package.bat
>>> links CRT statically (-DLLVM_USE_CRT_RELEASE=MT), whereas default

Re: [lldb-dev] Prebuilt binary for Windows

[Zachary Turner via lldb-dev]

Definitely seems CRT / Python related.  The call to fgets indicates that
it's doing something involving a FILE*.  It's probably a FILE* that refers
to a file created from within Python's copy of the CRT.  Another problem
that dynamic linking would solve.  Can you confirm that the problem does
not occur when LLDB links dynamically?

On Wed, Jan 11, 2017 at 1:14 PM Vadim Chugunov  wrote:

> BTW, here's the call stack at the point of failure.   I don't see anything
> Python-related in it, so maybe it's some other CRT interaction.
>
> liblldb!_invoke_watson(wchar_t * expression = 0x "", wchar_t *
> function_name = 0x "", wchar_t * file_name = 0x "",
> unsigned int line_number = 0, unsigned int reserved = 0)+0xe
> liblldb!_invalid_parameter(wchar_t * expression =  error>, wchar_t * function_name = , wchar_t *
> file_name = , unsigned int line_number =  unavailable error>, unsigned int reserved = )+0x7a
> liblldb!_invalid_parameter_noinfo(void)+0xc
> liblldb!_read(int fh = 0n0, void * buffer = 0x05afbb50, unsigned int
> buffer_size = 0x1000)+0x10a
> liblldb!common_refill_and_read_nolock(class __crt_stdio_stream
> stream = class __crt_stdio_stream)+0x9f
> liblldb!_fgetc_nolock(struct _iobuf * public_stream = 0x05af9c58)+0x2d
> liblldb!__crt_char_traits::getc_nolock+0x8
> liblldb!common_fgets(char * string = 0x019cf41c "b", int count =
> 0n256, class __crt_stdio_stream stream = class __crt_stdio_stream)+0x81
> liblldb!lldb_private::IOHandlerEditline::GetLine(class
> std::basic_string,std::allocator > * line
> = 0x019cf548 "", bool * interrupted = 0x019cf537)+0xd6
> liblldb!lldb_private::IOHandlerEditline::Run(void)+0x11a
> liblldb!lldb_private::Debugger::ExecuteIOHandlers(void)+0x35
> liblldb!lldb_private::CommandInterpreter::RunCommandInterpreter(bool
> auto_handle_events = true, bool spawn_thread = false, class
> lldb_private::CommandInterpreterRunOptions * options = 0x05af9ca8)+0x7e
> liblldb!lldb::SBDebugger::RunCommandInterpreter(bool auto_handle_events =
> true, bool spawn_thread = false, class lldb::SBCommandInterpreterRunOptions
> * options = 0x019cf604, int * num_errors = 0x019cf630, bool *
> quit_requested = 0x019cf603, bool * stopped_for_crash = 0x019cf60a)+0x43
> lldb!Driver::MainLoop(void)+0x639
> lldb!wmain(int argc = 0n3, wchar_t ** wargv = 0x01b28c90)+0x249
> lldb!invoke_main+0x1d
> lldb!__scrt_common_main_seh(void)+0xff
> KERNEL32!BaseThreadInitThunk+0x24
> ntdll_76f3!__RtlUserThreadStart+0x2f
> ntdll_76f3!_RtlUserThreadStart+0x1b
>
> On Wed, Jan 11, 2017 at 1:10 PM, Adrian McCarthy via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> I agree that linking to them dynamically is safer, but then you get into
> the deployment problem.  You do have to redistribute the DLLs for users
> using anything less than Windows 10.
>
> There are several options for doing that:  VCRedist, MSMs, MSUs, and
> app-local deployment.  They each have drawbacks.
>
> On Wed, Jan 11, 2017 at 1:00 PM, Zachary Turner 
> wrote:
>
> If we do that though, we still get 2 copies of the CRT.  One for python
> and one for LLDB.  While I *think* there is a strong enough API boundary in
> how the application and Python access each others' data structures that it
> doesn't matter, I'm not 100% sure without further research.  It seems safer
> to link dynamically unless there is a strong reason not to.
>
> On Wed, Jan 11, 2017 at 12:41 PM Adrian McCarthy 
> wrote:
>
> I was just reading up on this the other day.  Statically linking to the
> Universal CRT (and related libraries) *is* supported though it's not
> Microsoft's top recommendation.
>
> Initially, they said they weren't going to support app-local deployment,
> but they backed off on that, and it, too, is now supported.
>
> Some details here:
> https://blogs.msdn.microsoft.com/vcblog/2016/04/18/c-runtime-deployment-why-choosing-applocal/
>
>
> On Wed, Jan 11, 2017 at 10:51 AM, Reid Kleckner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> The purpose of linking the CRT statically was to ensure that clang can run
> on systems that don't have the CRT already installed from some other app or
> by VS itself. As long as that is preserved, feel free to do whatever you
> need.
>
> I think we still want to link vcruntime140 statically and the C++ runtime
> statically, for example.
>
> On Wed, Jan 11, 2017 at 10:45 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Is static CRT even still supported / recommended when using the new
> Universal CRT?  My understanding is the new UCRT is considered a core
> windows component, so we don't ahve to distribute redistributables
> anymore.  Maybe I'm wrong about this.
>
> That said, I think we want dynamic regardless, otherwise we're back in the
> same boat of user having to compile Python, which is the exact thing 3.5+
> is supposed to solve.  We should just always use dynamic so the user
> doesn't have to do anything and it just works.
>
> On Wed, Jan 11, 2017 at 10:41 AM Vadim Chugunov  

[lldb-dev] [Bug 31611] New: error: calling 'f' with incomplete return type 'string' (aka 'std::__cxx11::basic_string, std::allocator >')

[via lldb-dev]

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

Bug ID: 31611
   Summary: error: calling 'f' with incomplete return type
'string' (aka 'std::__cxx11::basic_string, std::allocator >')
   Product: lldb
   Version: 3.9
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: safinas...@mail.ru
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

root@ideal-os:~# cat /o.cpp
#include 

std::string
f (void)
{
  return "abc";
}

int
main (void)
{
  f ();
}
root@ideal-os:~# clang++-3.9 -g -o /o /o.cpp
root@ideal-os:~# lldb-3.9 /o
(lldb) target create "/o"
Current executable set to '/o' (x86_64).
(lldb) b main
Breakpoint 1: where = o`main + 12 at o.cpp:12, address = 0x0040084c
(lldb) r
Process 146 launched: '/o' (x86_64)
Process 146 stopped
* thread #1: tid = 146, 0x0040084c o`main + 12 at o.cpp:12, name = 'o',
stop reason = breakpoint 1.1
frame #0: 0x0040084c o`main + 12 at o.cpp:12
(lldb) p f ()
error: calling 'f' with incomplete return type 'string' (aka
'std::__cxx11::basic_string, std::allocator
>')
'f' declared here
forward declaration of 'std::__cxx11::basic_string, std::allocator >'
(lldb) root@ideal-os:~# 
root@ideal-os:~# dpkg -l lldb-3.9 clang-3.9
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  clang-3.9  1:3.9.1-2amd64C, C++ and
Objective-C compiler (LLVM based)
ii  lldb-3.9   1:3.9.1-2amd64Next generation,
high-performance debugger
root@ideal-os:~# lldb-3.9 --version
lldb version 3.9.1 ( revision )
root@ideal-os:~# clang-3.9 -v
clang version 3.9.1-2 (tags/RELEASE_391/rc2)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.3.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
root@ideal-os:~#

debian gnu/linux sid. clang and lldb from debian repo. amd64

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

[lldb-dev] [Bug 31612] New: Cannot eval function which returns empty struct. Error [IRForTarget]: Size of result type 'struct foo { }' couldn't be determined

[via lldb-dev]

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

Bug ID: 31612
   Summary: Cannot eval function which returns empty struct. Error
[IRForTarget]: Size of result type 'struct foo { }'
couldn't be determined
   Product: lldb
   Version: 3.9
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: safinas...@mail.ru
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

root@ideal-os:~# cat /o.cpp
struct foo
{
};

foo
f (void)
{
  return {};
}

int
main (void)
{
  f ();
}
root@ideal-os:~# clang++-3.9 -std=c++11 -g -o /o /o.cpp
root@ideal-os:~# lldb-3.9 /o
(lldb) target create "/o"
Current executable set to '/o' (x86_64).
(lldb) b main
Breakpoint 1: where = o`main + 4 at o.cpp:14, address = 0x004004e4
(lldb) r
Process 366 launched: '/o' (x86_64)
Process 366 stopped
* thread #1: tid = 366, 0x004004e4 o`main + 4 at o.cpp:14, name = 'o',
stop reason = breakpoint 1.1
frame #0: 0x004004e4 o`main + 4 at o.cpp:14
(lldb) p f ()
Error [IRForTarget]: Size of result type 'struct foo {
}' couldn't be determined
error: The expression could not be prepared to run in the target
(lldb)

Environment same as in https://llvm.org/bugs/show_bug.cgi?id=31611

-- 
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] Prebuilt binary for Windows

[Zachary Turner via lldb-dev]

On Wed, Jan 11, 2017 at 1:47 PM Vadim Chugunov  wrote:

> > Definitely seems CRT / Python related.  The call to fgets indicates that
> it's doing something involving a FILE*.  It's probably a FILE* that refers
> to a file created from within Python's copy of the CRT.
>
> Any idea where in the code would that be?  Would be nice to confirm.
>

Maybe in ScriptInterpreterPython somewhere?  There's a couple of places
where we use FILE* in that file, but it's not easy to tell by inspection
whether the FILE*'s originate from something in Python.

More likely perhaps is to try putting a breakpoint in PythonDataObjects.cpp
line 983 (called when try to create a wrapper around a Python File object
so we can reference it from C++) and Line 1010 (called when we try to
create a Python file object out of a native file descriptor).  These are
the two major API boundaries where we convert between native file
descriptors and python file objects.
___
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]

Okay, as far as I can see, the issue is not with Python, but that lldb.exe
and liblldb.dll have their own private copies of the CRT.

When 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.
​
___
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

[Zachary Turner via lldb-dev]

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?

On Wed, Jan 11, 2017 at 3:45 PM Vadim Chugunov  wrote:

> Okay, as far as I can see, the issue is not with Python, but that lldb.exe
> and liblldb.dll have their own private copies of the CRT.
>
> When 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.
> ​
>
___
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]

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