Re: [lldb-dev] LLDB build at windows

[Vadim Chugunov via lldb-dev]

>
>  VS 2013 support is going to be deprecated soon. At that point it could

break any time, because nobody is going to be making an effort to keep it >
> working.
>
How is this going to play with Python scripting on Windows?   Given
that LLDB only supports Python 2.7 bindings,
and that Python 2.7 extensions can be built only with VS2008, isn't
that going to be a problem?
(When LLDB for Windows is officially declared "ready", that is.  For
now, one can rebuild Python with VS2015.)

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

[lldb-dev] Spurious process state change events

[Vadim Chugunov via lldb-dev]

Hi,
I have a Python script that drives LLDB (in async mode), with a
listener attached to the process.
On OSX, upon the launch, LLDB emits a eStateRunning process state
event, and then eventually eStateStopped - when a breakpoint is hit.
On Linux, however, the initial eStateRunning is immediately followed
by eStateStopped and another eStateRunning, without any intervention
on my part.  This messes things up for me somewhat, because my script
thinks that a breakpoint has been hit and tries examine state of the
process.
So I have 2 questions:
- Is it supposed to happen?
- What would be the best way to filter out these spurious stop events?
  if is_linux and is_first_stop_event: ...  feels a bit hacky.

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

Re: [lldb-dev] Spurious process state change events

[Vadim Chugunov via lldb-dev]

+lldb-dev

On Fri, Jan 15, 2016 at 1:47 PM, Vadim Chugunov  wrote:

> Thanks, that was it!
>
> On Fri, Jan 15, 2016 at 1:00 PM, Pavel Labath  wrote:
>
>> Hi,
>>
>> The stopped event should have the "restarted" flag set. You can use
>> the GetRestartedFromEvent function to check for that. (Let me know if
>> they don't). I think you can get this (under varying circumstances) on
>> other platforms as well, so you need to handle this everywhere.
>>
>> Somebody correct me if I'm wrong, but I believe that every restarted
>> should be then followed by a running event.
>>
>> cheers,
>> pl
>>
>>
>> On 15 January 2016 at 19:35, Vadim Chugunov via lldb-dev
>>  wrote:
>> > Hi,
>> > I have a Python script that drives LLDB (in async mode), with a
>> > listener attached to the process.
>> > On OSX, upon the launch, LLDB emits a eStateRunning process state
>> > event, and then eventually eStateStopped - when a breakpoint is hit.
>> > On Linux, however, the initial eStateRunning is immediately followed
>> > by eStateStopped and another eStateRunning, without any intervention
>> > on my part.  This messes things up for me somewhat, because my script
>> > thinks that a breakpoint has been hit and tries examine state of the
>> > process.
>> > So I have 2 questions:
>> > - Is it supposed to happen?
>> > - What would be the best way to filter out these spurious stop events?
>> >   if is_linux and is_first_stop_event: ...  feels a bit hacky.
>> >
>> > thanks!
>> > ___
>> > lldb-dev mailing list
>> > lldb-dev@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Selectively disabling value formatter

[Vadim Chugunov via lldb-dev]

Hi,
If I have an SBValue for an object whose type has a formatter enabled for
it, is there a way to detect this via the Python API, and if so, request an
"unmodified" view of the object?
I've experimented with value.IsSynthetic() and
value.GetNonSyntheticValue(), but the former seems to always return false,
and the latter gives me the same list of children as the original value.

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

Re: [lldb-dev] Selectively disabling value formatter

[Vadim Chugunov via lldb-dev]

On Mon, Jan 25, 2016 at 11:04 AM, Enrico Granata  wrote:

>
> On Jan 25, 2016, at 12:23 AM, Vadim Chugunov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi,
> If I have an SBValue for an object whose type has a formatter enabled for
> it, is there a way to detect this via the Python API, and if so, request an
> "unmodified" view of the object?
>
>
> There definitely is a way for synthetic children, as you discovered below
> For type formats, you can simply set the format on the SBValue on an
> individual basis (SBValue::SetFormat)
> As for summaries, no, there is no way, as that would be nonsensical (don’t
> like the summary? just don’t ask for it - but there’s no meaning to getting
> the summary of a value once you disabled its summary)
>

Yes, this is about synthetic children.  Summaries are not a problem.


>
> I've experimented with value.IsSynthetic() and
> value.GetNonSyntheticValue(), but the former seems to always return false,
> and the latter gives me the same list of children as the original value.
>
>
> Do you have a reproduction case I can look at?
>

My setup is kinda complicated, I want to make sure I am using the API
correctly before attempting to create a self-contained repro case.


> GetNonSyntheticValue() returning self is correct behavior if IsSynthetic()
> == False; but if there really is a synthetic provider attached to the
> object, IsSynthetic() should definitely return True
>
>
Whose IsSynthetic() is supposed to return True,- the parent's or the
child's?
And on which object should I be calling GetNonSyntheticValue()?  (I assume
on the parent?)

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

Re: [lldb-dev] Selectively disabling value formatter

[Vadim Chugunov via lldb-dev]

lldb-340.4.119 (OSX 10.11.3)

On Mon, Jan 25, 2016 at 3:42 PM, Siva Chandra 
wrote:

> On Mon, Jan 25, 2016 at 12:23 AM, Vadim Chugunov via lldb-dev
>  wrote:
> > Hi,
> > If I have an SBValue for an object whose type has a formatter enabled for
> > it, is there a way to detect this via the Python API, and if so, request
> an
> > "unmodified" view of the object?
> > I've experimented with value.IsSynthetic() and
> value.GetNonSyntheticValue(),
> > but the former seems to always return false, and the latter gives me the
> > same list of children as the original value.
>
> This was a problem way back in June '15 and Enrico fixed it. Which
> version of LLDB are you using?
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Catching async debugger output

[Vadim Chugunov via lldb-dev]

Hello,
Is there a way for a python script to catch asynchronous debugger output,
such as the output of stop hooks?  I've tried attaching a listener to
CommandInterpreter's broadcaster, but no events seem to be ever fired.
Anything else I should try?

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

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Vadim Chugunov via lldb-dev]

> Does the 4.0 binary not work for you? It is the first release that contains
prebuilt lldb binary.

Looks like the Python API is not included though.   Do you know why it was
left out?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Vadim Chugunov via lldb-dev]

It outputs 'c:\Program Files (x86)\LLVM\lib\site-packages', however the
'site-packages' directory does not exist.  Nor do I see '_lldb.pyd'
anywhere else.
'script import lldb' also fails, of course.

On Tue, Oct 11, 2016 at 4:01 PM, Zachary Turner  wrote:

> He said he did, so I don't know.  Vadim, can you elaborate?  When you run
> `lldb -P` from the command line, what do you see?
>
> On Tue, Oct 11, 2016 at 4:00 PM Reid Kleckner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I imagine that Hans doesn't have Python 3 installed on his system, so
>> LLDB didn't autoconfigure with Python support.
>>
>> On Sun, Oct 9, 2016 at 1:07 PM, Vadim Chugunov via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> > Does the 4.0 binary not work for you? It is the first release that contains
>> prebuilt lldb binary.
>>
>> Looks like the Python API is not included though.   Do you know why it
>> was left out?
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Vadim Chugunov via lldb-dev]

Nope, that didn't help.

On Tue, Oct 11, 2016 at 5:16 PM, Zachary Turner  wrote:

> I may know what this is.  Can you try setting PYTHONPATH though to point
> to your Python 3.5 installation though and see if it fixes it?  (I don't
> think it will, but let's try anyway)
>
> On Tue, Oct 11, 2016 at 4:59 PM Vadim Chugunov  wrote:
>
>> It outputs 'c:\Program Files (x86)\LLVM\lib\site-packages', however the
>> 'site-packages' directory does not exist.  Nor do I see '_lldb.pyd'
>> anywhere else.
>> 'script import lldb' also fails, of course.
>>
>> On Tue, Oct 11, 2016 at 4:01 PM, Zachary Turner 
>> wrote:
>>
>> He said he did, so I don't know.  Vadim, can you elaborate?  When you run
>> `lldb -P` from the command line, what do you see?
>>
>> On Tue, Oct 11, 2016 at 4:00 PM Reid Kleckner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> I imagine that Hans doesn't have Python 3 installed on his system, so
>> LLDB didn't autoconfigure with Python support.
>>
>> On Sun, Oct 9, 2016 at 1:07 PM, Vadim Chugunov via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> > Does the 4.0 binary not work for you? It is the first release that contains
>> prebuilt lldb binary.
>>
>> Looks like the Python API is not included though.   Do you know why it
>> was left out?
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Vadim Chugunov via lldb-dev]

This is still broken in the October snapshot.   Do you know which script is
used to build the Windows installer?

On Tue, Oct 11, 2016 at 6:24 PM, Zachary Turner  wrote:

> I think it is a problem with the way we built lldb.  I will look into what
> additional steps we need to take when making the prebuilt binary so that it
> works next time.
>
> On Tue, Oct 11, 2016 at 6:20 PM Vadim Chugunov  wrote:
>
>> Nope, that didn't help.
>>
>> On Tue, Oct 11, 2016 at 5:16 PM, Zachary Turner 
>> wrote:
>>
>> I may know what this is.  Can you try setting PYTHONPATH though to point
>> to your Python 3.5 installation though and see if it fixes it?  (I don't
>> think it will, but let's try anyway)
>>
>> On Tue, Oct 11, 2016 at 4:59 PM Vadim Chugunov  wrote:
>>
>> It outputs 'c:\Program Files (x86)\LLVM\lib\site-packages', however the
>> 'site-packages' directory does not exist.  Nor do I see '_lldb.pyd'
>> anywhere else.
>> 'script import lldb' also fails, of course.
>>
>> On Tue, Oct 11, 2016 at 4:01 PM, Zachary Turner 
>> wrote:
>>
>> He said he did, so I don't know.  Vadim, can you elaborate?  When you run
>> `lldb -P` from the command line, what do you see?
>>
>> On Tue, Oct 11, 2016 at 4:00 PM Reid Kleckner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> I imagine that Hans doesn't have Python 3 installed on his system, so
>> LLDB didn't autoconfigure with Python support.
>>
>> On Sun, Oct 9, 2016 at 1:07 PM, Vadim Chugunov via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> > Does the 4.0 binary not work for you? It is the first release that contains
>> prebuilt lldb binary.
>>
>> Looks like the Python API is not included though.   Do you know why it
>> was left out?
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Vadim Chugunov via lldb-dev]

Please correct me if I'm wrong, but isn't the issue here that LLDB's Python
support files don't get packaged into the Windows installer?   Does
packaging them somehow depend on knowing what the Python installation path
is?

On Mon, Nov 28, 2016 at 10:09 AM, Hans Wennborg  wrote:

> The snapshots are built with the script in
> utils/release/build_llvm_package.bat. It's currently passing
> -DLLDB_RELOCATABLE_PYTHON=1 and  -DPYTHON_HOME=.
>
> I was planning on trying to build a new snapshot today and can add
> -DLLDB_DEFAULT_PYTHON_HOME if you think that will help.
>
> On Mon, Nov 28, 2016 at 9:51 AM, Zachary Turner 
> wrote:
> > So it sounds like you're saying that in order for Python support to work
> as
> > part of an LLDB shipped in the installer, we need to do set 3 variables
> at
> > CMake time.
> >
> > 1) -DLLDB_RELOCATABLE_PYTHON=TRUE
> > 2) -DPYTHON_HOME = 
> > 3) -DLLDB_DEFAULT_PYTHON_HOME=TRUE
> >
> > Now because of #3, the lldb shipped in the installer will use the
> PYTHONHOME
> > system environment variable to locate python, which must point to a valid
> > Python 3.5 installation.  Is this correct?
> >
> > On Mon, Nov 28, 2016 at 9:35 AM Ted Woodward <
> ted.woodw...@codeaurora.org>
> > wrote:
> >>
> >> Windows has no concept of a default python installation, and I can’t be
> >> sure what version of python my users have, if any, so I need to solve 2
> >> problems:
> >>
> >> 1)  Where is python when I’m building?
> >>
> >> 2)  Where is python when I’m running?
> >>
> >>
> >>
> >> To solve #1, I set LLDB_RELOCATABLE_PYTHON to TRUE, and PYTHON_HOME to
> my
> >> python installation (on our buildbots, c:/python351).
> >>
> >>
> >>
> >> #2 only needs to be solved if the machine you’re running on doesn’t have
> >> the same python installation, in PYTHON_HOME above. To do that, I’ve
> added
> >> code to set a cmake path LLDB_DEFAULT_PYTHONHOME, which I pass as a
> macro
> >> down to InitializePythonHome in
> >> source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp,
> and
> >> call Py_SetPythonHome with it. My installations have the python dll and
> >> python library directory. We put the library in /lib/python35
> and
> >> the dll in /bin.
> >>
> >> --
> >>
> >> Qualcomm Innovation Center, Inc.
> >>
> >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> >> Linux Foundation Collaborative Project
> >>
> >>
> >>
> >> From: Zachary Turner [mailto:ztur...@google.com]
> >> Sent: Wednesday, November 23, 2016 12:40 PM
> >> To: Vadim Chugunov 
> >> Cc: Reid Kleckner ; Hans Wennborg ;
> >> LLDB ; Ted Woodward <
> ted.woodw...@codeaurora.org>
> >> Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7
> >>
> >>
> >>
> >> I believe the way to fix this is going to be building LLDB for the
> >> installer with LLDB_RELOCATABLE_PYTHON=1 at CMake time
> >>
> >>
> >>
> >> +Ted, since I believe he is one of the few people currently using this
> >> flag.
> >>
> >> On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov 
> wrote:
> >>
> >> This is still broken in the October snapshot.   Do you know which script
> >> is used to build the Windows installer?
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 6:24 PM, Zachary Turner 
> >> wrote:
> >>
> >> I think it is a problem with the way we built lldb.  I will look into
> what
> >> additional steps we need to take when making the prebuilt binary so
> that it
> >> works next time.
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 6:20 PM Vadim Chugunov 
> wrote:
> >>
> >> Nope, that didn't help.
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 5:16 PM, Zachary Turner 
> >> wrote:
> >>
> >> I may know what this is.  Can you try setting PYTHONPATH though to point
> >> to your Python 3.5 installation though and see if it fixes it?  (I don't
> >> think it will, but let's try anyway)
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 4:59 PM Vadim Chugunov 
> wrote:
> >>
> >> It outputs 'c:\Program Files (x86)\LLVM\lib\site-packages', however the
> >> 'site-packages' 

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Vadim Chugunov via lldb-dev]

;> wrote:
>> >>
>> >> I think it is a problem with the way we built lldb.  I will look into
>> what
>> >> additional steps we need to take when making the prebuilt binary so
>> that it
>> >> works next time.
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 at 6:20 PM Vadim Chugunov 
>> wrote:
>> >>
>> >> Nope, that didn't help.
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 at 5:16 PM, Zachary Turner 
>> >> wrote:
>> >>
>> >> I may know what this is.  Can you try setting PYTHONPATH though to
>> point
>> >> to your Python 3.5 installation though and see if it fixes it?  (I
>> don't
>> >> think it will, but let's try anyway)
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 at 4:59 PM Vadim Chugunov 
>> wrote:
>> >>
>> >> It outputs 'c:\Program Files (x86)\LLVM\lib\site-packages', however the
>> >> 'site-packages' directory does not exist.  Nor do I see '_lldb.pyd'
>> anywhere
>> >> else.
>> >>
>> >> 'script import lldb' also fails, of course.
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 at 4:01 PM, Zachary Turner 
>> >> wrote:
>> >>
>> >> He said he did, so I don't know.  Vadim, can you elaborate?  When you
>> run
>> >> `lldb -P` from the command line, what do you see?
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 at 4:00 PM Reid Kleckner via lldb-dev
>> >>  wrote:
>> >>
>> >> I imagine that Hans doesn't have Python 3 installed on his system, so
>> LLDB
>> >> didn't autoconfigure with Python support.
>> >>
>> >>
>> >>
>> >> On Sun, Oct 9, 2016 at 1:07 PM, Vadim Chugunov via lldb-dev
>> >>  wrote:
>> >>
>> >> > Does the 4.0 binary not work for you? It is the first release that
>> >> > contains prebuilt lldb binary.
>> >>
>> >>
>> >>
>> >> Looks like the Python API is not included though.   Do you know why it
>> was
>> >> left out?
>> >>
>> >>
>> >>
>> >>
>> >> ___
>> >> lldb-dev mailing list
>> >> lldb-dev@lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >>
>> >>
>> >>
>> >> ___
>> >> lldb-dev mailing list
>> >> lldb-dev@lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>>
>>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Vadim Chugunov via lldb-dev]

ennborg ;
>> >> LLDB ; Ted Woodward <
>> ted.woodw...@codeaurora.org>
>> >> Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7
>> >>
>> >>
>> >>
>> >> I believe the way to fix this is going to be building LLDB for the
>> >> installer with LLDB_RELOCATABLE_PYTHON=1 at CMake time
>> >>
>> >>
>> >>
>> >> +Ted, since I believe he is one of the few people currently using this
>> >> flag.
>> >>
>> >> On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov 
>> wrote:
>> >>
>> >> This is still broken in the October snapshot.   Do you know which
>> script
>> >> is used to build the Windows installer?
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 at 6:24 PM, Zachary Turner 
>> >> wrote:
>> >>
>> >> I think it is a problem with the way we built lldb.  I will look into
>> what
>> >> additional steps we need to take when making the prebuilt binary so
>> that it
>> >> works next time.
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 at 6:20 PM Vadim Chugunov 
>> wrote:
>> >>
>> >> Nope, that didn't help.
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 at 5:16 PM, Zachary Turner 
>> >> wrote:
>> >>
>> >> I may know what this is.  Can you try setting PYTHONPATH though to
>> point
>> >> to your Python 3.5 installation though and see if it fixes it?  (I
>> don't
>> >> think it will, but let's try anyway)
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 at 4:59 PM Vadim Chugunov 
>> wrote:
>> >>
>> >> It outputs 'c:\Program Files (x86)\LLVM\lib\site-packages', however the
>> >> 'site-packages' directory does not exist.  Nor do I see '_lldb.pyd'
>> anywhere
>> >> else.
>> >>
>> >> 'script import lldb' also fails, of course.
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 at 4:01 PM, Zachary Turner 
>> >> wrote:
>> >>
>> >> He said he did, so I don't know.  Vadim, can you elaborate?  When you
>> run
>> >> `lldb -P` from the command line, what do you see?
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 at 4:00 PM Reid Kleckner via lldb-dev
>> >>  wrote:
>> >>
>> >> I imagine that Hans doesn't have Python 3 installed on his system, so
>> LLDB
>> >> didn't autoconfigure with Python support.
>> >>
>> >>
>> >>
>> >> On Sun, Oct 9, 2016 at 1:07 PM, Vadim Chugunov via lldb-dev
>> >>  wrote:
>> >>
>> >> > Does the 4.0 binary not work for you? It is the first release that
>> >> > contains prebuilt lldb binary.
>> >>
>> >>
>> >>
>> >> Looks like the Python API is not included though.   Do you know why it
>> was
>> >> left out?
>> >>
>> >>
>> >>
>> >>
>> >> ___
>> >> lldb-dev mailing list
>> >> lldb-dev@lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >>
>> >>
>> >>
>> >> ___
>> >> lldb-dev mailing list
>> >> lldb-dev@lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>>
>>
>>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Vadim Chugunov via lldb-dev]

Hi Hans,

I'd love to help, but I don't have half the tools that build_llvm_package.bat
requires installed on my machine.  My setup is to build llvm with msbuild.
  Is it possible to build the installer this way too?

Can you point me to the specific CMake source that determines what's
included in the package?   At a glance, everything from
%LLVM%/lib/site-packages is missing.

Vadim

On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg  wrote:

> Is anyone working on this?
>
I'm happy to include LLDB in the installer, but I'm really not the
> best person to be debugging it.
>
> If more files need to be included in the install, that's configured in
> the CMake files (what's installed by the 'install' build target is
> also what ends up going into the installer). If it needs more build
> flags, patches to build_llvm_package.bat are welsome.
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Vadim Chugunov via lldb-dev]

I am having no luck building LLDB with ninja, and there doesn't seem to be
a "package" target in the generated msbuild solution file, but here's something
interesting

I found in cmake files.  Could this be the reason why Python modules aren't
being installed on Windows?

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 installed on my machine.  My setup is to
> > build llvm with msbuild.   Is it possible to build the installer this way
> > too?
> >
> > Can you point me to the specific CMake source that determines what's
> > included in the package?   At a glance, everything from
> > %LLVM%/lib/site-packages is missing.
> >
> > Vadim
> >
> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg 
> wrote:
> >>
> >> Is anyone working on this?
> >>
> >> I'm happy to include LLDB in the installer, but I'm really not the
> >> best person to be debugging it.
> >>
> >> If more files need to be included in the install, that's configured in
> >> the CMake files (what's installed by the 'install' build target is
> >> also what ends up going into the installer). If it needs more build
> >> flags, patches to build_llvm_package.bat are welsome.
> >
> >
> >
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Vadim Chugunov via lldb-dev]

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 installed on my machine.  My setup is to
> > build llvm with msbuild.   Is it possible to build the installer this way
> > too?
> >
> > Can you point me to the specific CMake source that determines what's
> > included in the package?   At a glance, everything from
> > %LLVM%/lib/site-packages is missing.
> >
> > Vadim
> >
> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg 
> wrote:
> >>
> >> Is anyone working on this?
> >>
> >> I'm happy to include LLDB in the installer, but I'm really not the
> >> best person to be debugging it.
> >>
> >> If more files need to be included in the install, that's configured in
> >> the CMake files (what's installed by the 'install' build target is
> >> also what ends up going into the installer). If it needs more build
> >> flags, patches to build_llvm_package.bat are welsome.
> >
> >
> >
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Prebuilt binary for Windows

[Vadim Chugunov via lldb-dev]

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 installed on my machine.  My setup is to
>> > build llvm with msbuild.   Is it possible to build the installer this
>> way
>> > too?
>> >
>> > Can you point me to the specific CMake source that determines what's
>> > included in the package?   At a glance, everything from
>> > %LLVM%/lib/site-packages is missing.
>> >
>> > Vadim
>> >
>> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg 
>> wrote:
>> >>
>> >> Is anyone working on this?
>> >>
>> >> I'm happy to include LLDB in the installer, but I'm really not the
>> >> best person to be debugging it.
>> >>
>> >> If more files need to be included in the install, that's configured in
>> >> the CMake files (what's installed by the 'install' build target is
>> >> also what ends up going into the installer). If it needs more build
>> >> flags, patches to build_llvm_package.bat are welsome.
>> >
>> >
>> >
>>
>
>
___
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]

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 installed on my machine.  My setup is to
>> > build llvm with msbuild.   Is it possible to build the installer this
>> way
>> > too?
>> >
>> > Can you point me to the specific CMake source that determines what's
>> > included in the package?   At a glance, everything from
>> > %LLVM%/lib/site-packages is missing.
>> >
>> > Vadim
>> >
>> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg 
>> wrote:
>> >>
>> >> Is anyone working on this?
>> >>
>> >> I'm happy to include LLDB in the installer, but I'm really not the
>> >> best person to be debugging it.
>> >>
>> >> If more files need to be included in the install, that's configured in
>> >> the CMake files (what's installed by the 'install' build target is
>> >> also what ends up going into the installer). If it needs more build
>> >> flags, patches to build_llvm_package.bat are welsome.
>> >
>> >
>> >
>>
>>
>>
>>
___
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]

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 installed on my machine.  My setup
> >> > is to
> >> > build llvm with msbuild.   Is it possible to build the installer
> >> > this way
> >> > too?
> >> >
> >> > Can you point me to the specific CMake source that determines
> what's
> >> > included in the package?   At a glance, everything from
> >> > %LLVM%/lib/site-packages is missing.
> >> >
> >> > Vadim
> >> >
> >> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg  >
> >> > wrote:
> >> >>
> >> >> Is anyone working on this?
> >> >>
> >> >> I'm happy to include LLDB in the installer, but I'm really not
> the
> >> >> best person to be debugging it.
> >> >>
> >> >> If more files need to be included in the install, that's
> configured
> >> >> in
> >> >> the CMake files (what's installed by the 'install' build target
> is
> >> >> also what ends up going into the installer). If it needs more
> build
> >> >> flags, patches to build_llvm_package.bat are welsome.
> >> >
> >> >
> >> >
> >
> >
> 
> >>
> >
>
___
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]

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 installed on my machine.  My
>> setup
>> >> > is to
>> >> > build llvm with msbuild.   Is it possible to build the installer
>> >> > this way
>> >> > too?
>> >> >
>> >> > Can you point me to the specific CMake source that determines
>> what's
>> >> > included in the package?   At a glance, everything from
>> >> > %LLVM%/lib/site-packages is missing.
>> >> >
>> >> > Vadim
>> >> >
>> >> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg <
>> h...@chromium.org>
>> >> > wrote:
>> >> >>
>> >> >> Is anyone working on this?
>> >> >>
>> >> >> I'm happy to include LLDB in the installer, but I'm really not
>> the
>> >> >> best person to be debugging it.
>> >> >>
>> >> >> If more files need to be included in the install, that's
>> configured
>> >> >> in
>> >> >> the CMake files (what's installed by the 'install' build target
>> is
>> >> >> also what ends up going into the installer). If it needs more
>> build
>> >> >> flags, patches to build_llvm_package.bat are welsome.
>> >> >
>> >> >
>> >> >
>> >
>> >
>> 
>> >>
>> >
>>
>
>
___
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]

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.
> >> >>> >>
> >> >>> >> 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 installed on my machine.
> My
> >> >>> >> > setup
> >> >>> >> > is to
> >> >>> >> > build llvm with msbuild.   Is it possible to build the
> >> >>> >> > installer
> >> >>> >> > this way
> >> >>> >> > too?
> >> >>> >> >
> >> >>> >> > Can you point me to the specific CMake source that
> determines
> >> >>> >> > what's
> >> >>> >> > included in th

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

[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

[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

[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

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

[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
<https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/>).
  I've opened a bug <http://llvm.org/bugs/show_bug.cgi?id=31699> 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

[lldb-dev] Python scripting in Windows LLDB

[Vadim Chugunov via lldb-dev]

Hi!

I've just noticed that LLDB from the most recent LLVM Windows snapshot
build has Python scripting disabled.
Was this done on purpose and for what reason if so?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Python scripting in Windows LLDB

[Vadim Chugunov via lldb-dev]

Update: looks like Python detection in CMake now requires debug binaries to
be there as well (e.g. python35_d.dll), otherwise Python support gets
disabled.  I am wondering if Python the build machine was installed without
the debug stuff.

On Fri, May 19, 2017 at 10:52 AM, Vadim Chugunov  wrote:

> Hi!
>
> I've just noticed that LLDB from the most recent LLVM Windows snapshot
> build has Python scripting disabled.
> Was this done on purpose and for what reason if so?
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Python scripting in Windows LLDB

[Vadim Chugunov via lldb-dev]

Note that building with 3.6.x and using 3.5.x won't work, but any of 3.5.x
revisions should be compatible between themselves.

On Fri, Jun 30, 2017 at 1:41 PM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

>
>
> On Fri, Jun 30, 2017 at 1:34 PM Ted Woodward 
> wrote:
>
>> I’ve seen crashes on Linux when building with 2.7.6 and using the 2.7.3
>> .so/library directory, so I’m not willing to say building on Windows with
>> 3.6.1 and using the 3.5.2 dll/library directory will work. Python has never
>> been very forgiving when using a different setup than what you built with.
>>
> Well, never prior to 3.5 anyway.  That was literally one of the entire
> points of requiring 3.5+ on Windows.  Python for Windows post 3.5 uses the
> Universal CRT, which is forwards compatible. More information here:
> http://stevedower.id.au/blog/building-for-python-3-5/
>
> I can't speak to the issue of 2.7.6 vs 2.7.3 on Linux you experienced, but
> on Windows the officially supported position of the Python project is that
> you can install any version of Python post 3.5 and it "just works".
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] PDB symbol reader status?

[Vadim Chugunov via lldb-dev]

Hi,
What is the current status of LLDB's PDB file parser on Windows?   It was
announced back in 2015 that PDB support is coming soon, so I was wondering
where it's at currently.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] PDB symbol reader status?

[Vadim Chugunov via lldb-dev]

I'm trying to use LLDB built from svn trunk: for MSVC emitted binaries it
cannot set any breakpoints, and for clang-cl outputs it crashes when
setting a breakpoiint by file/line.   Are these scenarios supposed to work?
WinDbg works fine in both cases, so the debug info is probably ok.

(I'm using VS 2017 Build Tools, if that matters).

On Wed, Jul 26, 2017 at 11:54 AM, Adrian McCarthy 
wrote:

> Basic PDB support is in LLDB if you're running on Windows.  LLDB has a
> SymbolFilePDB plugin that relies on a PDB abstraction in LLVM.  There is
> currently just one implementation of that abstraction, and it relies on
> DIA, which is a Microsoft-provided DLL on Windows for looking up
> information in a PDB.
>
> I'm currently working on a native PDB reader that implements the same
> interface without reliance on DIA, so that should eventually provide the
> same functionality even if you're not running on Windows.
>
> Browsing through the PDB plugin in LLDB, I see a lot of "//TODO:
>  Implement this" methods, so you won't (yet) have rich type information.
> But you can set breakpoints by name, get a stack backtrace, print variable
> values, etc.
>
>
> On Wed, Jul 26, 2017 at 11:19 AM, Vadim Chugunov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi,
>> What is the current status of LLDB's PDB file parser on Windows?   It was
>> announced back in 2015 that PDB support is coming soon, so I was wondering
>> where it's at currently.
>>
>>
>> ___
>> 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] PDB symbol reader status?

[Vadim Chugunov via lldb-dev]

Why -fuse-ld=lld?   What does lld do differently than MS linker?

On Wed, Jul 26, 2017 at 1:10 PM, Zachary Turner  wrote:

> For clang-cl you need to use -fuse-ld=lld. For msvc only a small amount of
> pdb support was added to lldb, namely the ability to resolve file and line
> info.
> On Wed, Jul 26, 2017 at 12:46 PM Vadim Chugunov  wrote:
>
>> I'm trying to use LLDB built from svn trunk: for MSVC emitted binaries it
>> cannot set any breakpoints, and for clang-cl outputs it crashes when
>> setting a breakpoiint by file/line.   Are these scenarios supposed to work?
>> WinDbg works fine in both cases, so the debug info is probably ok.
>>
>> (I'm using VS 2017 Build Tools, if that matters).
>>
>> On Wed, Jul 26, 2017 at 11:54 AM, Adrian McCarthy 
>> wrote:
>>
>>> Basic PDB support is in LLDB if you're running on Windows.  LLDB has a
>>> SymbolFilePDB plugin that relies on a PDB abstraction in LLVM.  There is
>>> currently just one implementation of that abstraction, and it relies on
>>> DIA, which is a Microsoft-provided DLL on Windows for looking up
>>> information in a PDB.
>>>
>>> I'm currently working on a native PDB reader that implements the same
>>> interface without reliance on DIA, so that should eventually provide the
>>> same functionality even if you're not running on Windows.
>>>
>>> Browsing through the PDB plugin in LLDB, I see a lot of "//TODO:
>>>  Implement this" methods, so you won't (yet) have rich type information.
>>> But you can set breakpoints by name, get a stack backtrace, print variable
>>> values, etc.
>>>
>>>
>>> On Wed, Jul 26, 2017 at 11:19 AM, Vadim Chugunov via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>>> Hi,
>>>> What is the current status of LLDB's PDB file parser on Windows?   It
>>>> was announced back in 2015 that PDB support is coming soon, so I was
>>>> wondering where it's at currently.
>>>>
>>>>
>>>> ___
>>>> 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] PDB symbol reader status?

[Vadim Chugunov via lldb-dev]

Thanks, I know that dwarf works with lldb on Windows, but I was
specifically trying to debug a program compiled with pdb debug info.
(Why not a native Windows debugger?  Because I have existing code that uses
lldb api.)

On Fri, Jul 28, 2017 at 4:10 AM, Zachary Turner  wrote:

> It can handle linking dwarf debug info. Also I misspoke, you can't get
> dwarf debug info with clang-cl, but you can with clang++ on windows. Look
> at how the test suite on windows compiles the inferiors. That's currently
> the best debugging experience of Windows programs.
>
> Unfortunately i was never able to get the rest of windows support
> implemented as i got pulled off to add support for writing codeview/pdb to
> clang-cl
> On Wed, Jul 26, 2017 at 5:38 PM Vadim Chugunov  wrote:
>
>> Why -fuse-ld=lld?   What does lld do differently than MS linker?
>>
>>
>> On Wed, Jul 26, 2017 at 1:10 PM, Zachary Turner 
>> wrote:
>>
>>> For clang-cl you need to use -fuse-ld=lld. For msvc only a small amount
>>> of pdb support was added to lldb, namely the ability to resolve file and
>>> line info.
>>> On Wed, Jul 26, 2017 at 12:46 PM Vadim Chugunov 
>>> wrote:
>>>
>>>> I'm trying to use LLDB built from svn trunk: for MSVC emitted binaries
>>>> it cannot set any breakpoints, and for clang-cl outputs it crashes when
>>>> setting a breakpoiint by file/line.   Are these scenarios supposed to work?
>>>> WinDbg works fine in both cases, so the debug info is probably ok.
>>>>
>>>> (I'm using VS 2017 Build Tools, if that matters).
>>>>
>>>> On Wed, Jul 26, 2017 at 11:54 AM, Adrian McCarthy 
>>>> wrote:
>>>>
>>>>> Basic PDB support is in LLDB if you're running on Windows.  LLDB has a
>>>>> SymbolFilePDB plugin that relies on a PDB abstraction in LLVM.  There is
>>>>> currently just one implementation of that abstraction, and it relies on
>>>>> DIA, which is a Microsoft-provided DLL on Windows for looking up
>>>>> information in a PDB.
>>>>>
>>>>> I'm currently working on a native PDB reader that implements the same
>>>>> interface without reliance on DIA, so that should eventually provide the
>>>>> same functionality even if you're not running on Windows.
>>>>>
>>>>> Browsing through the PDB plugin in LLDB, I see a lot of "//TODO:
>>>>>  Implement this" methods, so you won't (yet) have rich type information.
>>>>> But you can set breakpoints by name, get a stack backtrace, print variable
>>>>> values, etc.
>>>>>
>>>>>
>>>>> On Wed, Jul 26, 2017 at 11:19 AM, Vadim Chugunov via lldb-dev <
>>>>> lldb-dev@lists.llvm.org> wrote:
>>>>>
>>>>>> Hi,
>>>>>> What is the current status of LLDB's PDB file parser on Windows?   It
>>>>>> was announced back in 2015 that PDB support is coming soon, so I was
>>>>>> wondering where it's at currently.
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> lldb-dev mailing list
>>>>>> lldb-dev@lists.llvm.org
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>>>
>>>>>>
>>>>>
>>>>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Forcing lldb to refresh process state

[Vadim Chugunov via lldb-dev]

Hi,
Is there any way to force lldb to refresh it's internal record of debuggee
process state (as if it had just received a stop event)?  I want to send a
custom command to remote gdb process stub (via `process plugin packet
send`).  This works, but if the command alters debuggee state, lldb won't
know about it.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Forcing lldb to refresh process state

[Vadim Chugunov via lldb-dev]

It does send '$T05...' in response, but it looks like lldb does not analyze
responses to manually sent packets.

On Mon, Aug 21, 2017 at 1:02 PM, Greg Clayton  wrote:

> If you do a reverse step it actually should send a process resumed and a
> process stopped event.
>
> > On Aug 18, 2017, at 7:19 PM, Vadim via lldb-dev 
> wrote:
> >
> > I'm trying to reverse-step.  So I think I'd need to refresh all thread
> states?
> >
> >> On Aug 18, 2017, at 4:50 PM, Jim Ingham  wrote:
> >>
> >> No, there hasn't been a need for this.
> >>
> >> What commands are you planning to send?  Or equivalently, how much
> state are you expecting to change?
> >>
> >> Jim
> >>
> >>> On Aug 18, 2017, at 4:36 PM, Vadim Chugunov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>>
> >>> Hi,
> >>> Is there any way to force lldb to refresh it's internal record of
> debuggee process state (as if it had just received a stop event)?  I want
> to send a custom command to remote gdb process stub (via `process plugin
> packet send`).  This works, but if the command alters debuggee state, lldb
> won't know about it.
> >>> ___
> >>> lldb-dev mailing list
> >>> lldb-dev@lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >>
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Forcing lldb to refresh process state

[Vadim Chugunov via lldb-dev]

Yeah, this `bs` + `stepi` dance is the only workaround I found so far.

On Wed, Aug 23, 2017 at 10:40 AM, Greg Clayton  wrote:

> There is a standard for reverse stepping where the GDB remote protocol was
> extended to do the reverse stepping. See:
>
> https://sourceware.org/gdb/onlinedocs/gdb/Packets.html
>
> Look for "reverse" in the text. They added "bc" for reverse continue and
> "bs" for reverse step. We should be using these if possible.
>
>
> On Aug 23, 2017, at 10:00 AM, Ted Woodward 
> wrote:
>
> Perhaps a manual packet that tells your remote server that the next “s”
> packet is a reverse step, then run the lldb command “si”.
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Forcing lldb to refresh process state

[Vadim Chugunov via lldb-dev]

On Wed, Aug 23, 2017 at 12:37 PM, Greg Clayton  wrote:

> This isn't a work around right? You should be triggering your reverse step
> or reverse continue using a "process reverse-continue" or "thread
> reverse-step" right? If you do this, everything will just work. There
> should be no way this happens automagically without user interaction. Am I
> missing something?
>

Wait a second... As far as I know, LLDB itself does not support
reverse-debugging (unless I missed something in a major way).  So there is
no "process reverse-continue" command, is there?

I am not talking about adding proper reverse-debugging to lldb.  All I want
to do is to hack together a script that emulates "process reverse-continue"
in cases when remote target happens to support it.   I'm sending commands
directly to remote gdb via `process plugin packet send bs`, but that leaves
lldb out of the loop because it does not analyze the response packet.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to test lldb-vscode?

[Vadim Chugunov via lldb-dev]

FYI - I've been maintaining a similar VSCode extension
,
which does it all through LLDB's Python interface.

As for testing, the protocol is JSON with HTTP-like headers for framing, so
you could have a Python script emulating the VSCode side.


On Wed, Feb 14, 2018 at 2:28 PM, Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I have a patch I will be submitting soon that adds a tool called
> "lldb-vscode" that is much like "lldb-mi" where it sits on top of
> LLDB.framework on Darwin and liblldb.so on all other platforms, and it
> speaks the Visual Studio Code Debug adaptor language and can be used to
> create a VSCode extension that does native LLDB debugging. The plug-in
> works really well to debug native apps and is very responsive and quick.
>
> One issue I am thinking about is how to test this. Some VS Code tests out
> there use Javascript + npm to run a mock VSCode IDE and send/receive
> packets. I am not sure we can require people to have this on all build
> bots. So I am writing to get everyone's opinion on this so I can test this
> and get a patch submitted.
>
> Any ideas would be appreciated.
>
> 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

Re: [lldb-dev] How to test lldb-vscode?

[Vadim Chugunov via lldb-dev]

My tests are here
.
I probably wouldn't move all that to Python for my extension, but feel free
to draw ideas on things to test from it.

What's going to be your deployment story?   The nice thing about
Python-based adapter is that it will run on a wide range on LLDB versions.
For a native adapter you'll need to somehow make sure that you have the
right liblldb installed, won't you?


On Wed, Feb 14, 2018 at 3:54 PM, Greg Clayton  wrote:

>
>
> On Feb 14, 2018, at 3:45 PM, Vadim Chugunov  wrote:
>
> FYI - I've been maintaining a similar VSCode extension
> ,
> which does it all through LLDB's Python interface.
>
>
> Indeed, I saw you plug-in and since it worked so well I wanted to make a
> native version of this plug-in to avoid taking over the python interpreter
> and get native performance. Very nice work on that plug-in as it inspired
> this one! I adopted many similar settings that you allow in the launch.json
> file and added some new ones.
>
>
> As for testing, the protocol is JSON with HTTP-like headers for framing,
> so you could have a Python script emulating the VSCode side.
>
>
> That is what I was planning to do. Might be nice to work together on this
> and get the testing working as it could test both of our plug-ins. Would be
> great to have a debug session with a simple program that sets a breakpoint
> by name, by file and line and exception and run, hit the breakpoints, view
> variables, etc.
>
> Greg
>
>
>
> On Wed, Feb 14, 2018 at 2:28 PM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I have a patch I will be submitting soon that adds a tool called
>> "lldb-vscode" that is much like "lldb-mi" where it sits on top of
>> LLDB.framework on Darwin and liblldb.so on all other platforms, and it
>> speaks the Visual Studio Code Debug adaptor language and can be used to
>> create a VSCode extension that does native LLDB debugging. The plug-in
>> works really well to debug native apps and is very responsive and quick.
>>
>> One issue I am thinking about is how to test this. Some VS Code tests out
>> there use Javascript + npm to run a mock VSCode IDE and send/receive
>> packets. I am not sure we can require people to have this on all build
>> bots. So I am writing to get everyone's opinion on this so I can test this
>> and get a patch submitted.
>>
>> Any ideas would be appreciated.
>>
>> 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

[lldb-dev] PDB symbol reader supports C++ only?

[Vadim Chugunov via lldb-dev]

Hi!
I've been investigating why LLDB refuses to set breakpoints in Rust source
files when using PDB debug info on Windows...  This seems to stem from a
couple of checks here

and here
.

I am wondering, what is the backstory there?  Are those still necessary?  I
tried disabling them and Rust debugging worked just fine...
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] PDB symbol reader supports C++ only?

[Vadim Chugunov via lldb-dev]

Would you mind going into a bit more detail on what sort of problems an
unknown language could cause?   I'd like to understand the issue before
jumping in to fix anything.  AFAIK, in the case of DWARF symbols, debug
info for unknown languages is still used, so it wouldn't be the first for
LLDB...

Also, the second fragment

checks for specific file extensions, which is an unreliable method, IMO,
since there's more extensions in use for c++ alone.  Code could also be
generated by a template engine, which will probably use a different
extension, etc.   I'd rather not just hardcode '.rs' for Rust.
I was hoping Aaron could commend on why this is necessary (i.e. why not
just trust the language flag?)

Thanks!

On Mon, Aug 20, 2018 at 7:35 PM Zachary Turner  wrote:

> Various parts of lldb require knowing the source language. It’s possible
> that things will mostly work if you report that the language is c++, but
> you’ll probably get errors in other areas. It goes all the way down to the
> CodeView level, where certain cv records indicate the original source
> language. Can you check cvconst.h (ships with DIA SDK) and look for the
> enumeration corresponding to source language? Does it have a value for
> Rust? I’m guessing it doesn’t. When you generate PDBs for Rust you probably
> need to put something unique value there, then we could properly set the
> language in lldb
> On Mon, Aug 20, 2018 at 7:15 PM Vadim Chugunov  wrote:
>
>> Hi!
>> I've been investigating why LLDB refuses to set breakpoints in Rust
>> source files when using PDB debug info on Windows...  This seems to stem
>> from a couple of checks here
>> 
>> and here
>> .
>>
>> I am wondering, what is the backstory there?  Are those still necessary?
>> I tried disabling them and Rust debugging worked just fine...
>>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] PDB symbol reader supports C++ only?

[Vadim Chugunov via lldb-dev]

These two changes ([1]
<https://github.com/vadimcn/llvm/commit/a8e52b43f4ca43594987ad900277bed7c005461b>
[2]
<https://github.com/vadimcn/lldb/commit/77d54fcbcb82b0b94bcfb238387b055489f3632e>)
appear to be sufficient to enable debugging of Rust binaries with pdb debug
info (make sure that msdia140.dll is somewhere lldb can find it).
At a cursory glance, I did not observe any ill effects of disabling that
language check, so I'm still not sure whether it was truly necessary, or
more of "Let's disable code paths we did not test".

As for allocating a language code for Rust, does Microsoft even have a
procedure for this?   In any case, looks like D folks had already staked out
<https://github.com/llvm-mirror/llvm/blob/d7e8f44ac5abf9599b718cf1438ffbe8adee5db9/include/llvm/DebugInfo/CodeView/CodeView.h#L165>
0x44 for themselves.   I suggest we claim 0x27  :-)

On Mon, Aug 27, 2018 at 6:32 AM Tom Tromey  wrote:

> >>>>> "Vadim" == Vadim Chugunov via lldb-dev 
> writes:
>
> Vadim> Would you mind going into a bit more detail on what sort of
> Vadim> problems an unknown language could cause?  I'd like to understand
> Vadim> the issue before jumping in to fix anything.  AFAIK, in the case
> Vadim> of DWARF symbols, debug info for unknown languages is still used,
> Vadim> so it wouldn't be the first for LLDB...
>
> LLDB checks for DW_LANG_Rust and uses the C++ plugin in this case.
>
> The Rust lldb (
> https://github.com/rust-lang-nursery/lldb/commits/rust-release-70)
> removes this.
>
> If you get something working, let me know.  I'd like to incorporate it
> into the Rust lldb.
>
> Tom
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Cross-building lldb

[Vadim Chugunov via lldb-dev]

Hi,
I'm trying (and failing) to cross-build lldb according to these instructions
.


My cmake command line:

cd /workspace/build/lldb && /usr/bin/cmake -DLLVM_VERSION_SUFFIX=-custom
-DLLVM_PARALLEL_LINK_JOBS=1 "-DLLVM_ENABLE_PROJECTS=clang;libcxx;lldb"
"-DLLVM_TARGETS_TO_BUILD=X86;AArch64;ARM" -DLLVM_ENABLE_TERMINFO=FALSE
-DLLVM_ENABLE_LIBXML2=FORCE_ON  -DLLDB_RELOCATABLE_PYTHON=TRUE
-DLLDB_DISABLE_CURSES=TRUE -DLLDB_DISABLE_LIBEDIT=TRUE
-DCMAKE_CXX_FLAGS="-static-libstdc++ -static-libgcc"
-DCMAKE_SYSTEM_NAME=Linux -DCMAKE_SYSTEM_PROCESSOR=aarch64
-DCMAKE_C_COMPILER=aarch64-linux-gnu-gcc
-DCMAKE_CXX_COMPILER=aarch64-linux-gnu-g++ -DCMAKE_CROSSCOMPILING=TRUE
-DLLVM_TARGET_ARCH=aarch64
-DLLVM_TABLEGEN=/workspace/build/llvm-host/bin/llvm-tblgen
-DCLANG_TABLEGEN=/workspace/build/llvm-host/bin/clang-tblgen
-DPYTHON_EXECUTABLE=/usr/bin/python3 -GNinja /workspace/source/llvm

When I kick off a build, a few files get compiled, but then a nested build
configuration is invoked:

cd /workspace/build/lldb/NATIVE && /usr/bin/cmake -G Ninja
-DCMAKE_MAKE_PROGRAM="/usr/bin/ninja"
-DCMAKE_C_COMPILER=/usr/bin/aarch64-linux-gnu-gcc
-DCMAKE_CXX_COMPILER=/usr/bin/aarch64-linux-gnu-g++ /workspace/source/llvm
-DLLVM_TARGET_IS_CROSSCOMPILE_HOST=TRUE
-DLLVM_TARGETS_TO_BUILD="X86;AArch64;ARM"
-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=""
-DLLVM_DEFAULT_TARGET_TRIPLE="x86_64-unknown-linux-gnu"
-DLLVM_TARGET_ARCH="aarch64" -DLLVM_ENABLE_PROJECTS="clang;libcxx;lldb"
-DLLVM_EXTERNAL_PROJECTS="" -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN="OFF"
-DCMAKE_BUILD_TYPE=Release
-DLLVM_EXTERNAL_CLANG_SOURCE_DIR=/workspace/source/llvm/../clang

... which fails with this error:

CMake Error at
/usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:137
(message):
  Could NOT find LibEdit (missing: libedit_LIBRARIES) (found version ".")
Call Stack (most recent call first):
  /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:378
(_FPHSA_FAILURE_MESSAGE)
  /workspace/source/lldb/cmake/modules/FindLibEdit.cmake:54
(find_package_handle_standard_args)
  /workspace/source/lldb/cmake/modules/LLDBConfig.cmake:104 (find_package)
  /workspace/source/lldb/CMakeLists.txt:21 (include)

As far as I can tell, this happens because LLDB_DISABLE_LIBEDIT is not
propagated to this nested build...  but maybe I am missing some cmake flag?
I'm building off of master, but the same thing happens with 9.0 release
branch.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Rust support in LLDB, again

[Vadim Chugunov via lldb-dev]

Hi,
Last year there was an effort led by Tom Tromey to add Rust language
support into LLDB.  He had implemented a fairly complete language plugin,
however it was not accepted into mainline because of supportability
concerns.I guess these concerns had some merit, because this change did
not survive even in Rust's private branch
 due to the difficulty
of rebasing on top of LLVM 9.

I am wondering if there's a more limited version of this, that *can* be
merged into mainline:
In terms of its memory model, Rust is not that far off from C++, so
treating Rust types is if they were C++ types basically works.  There is
only one major problem: currently LLDB cannot deal with tagged unions,
which Rust code uses quite heavily.   When such a type is encountered, LLDB
just emits an empty struct, which makes it impossible to examine the
contents.

My tentative proposal is to modify LLDB's DWARFASTParserClang to handle
DW_TAG_variant et al, and create a C++ approximation of these types, e.g.
as a polymorphic class, or just an untagged union.   This would provide at
least a minimal level of functionality for Rust (and possibly other
languages) and be a much lesser maintenance burden on LLDB core team.
What would y'all say?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Rust support in LLDB, again

[Vadim Chugunov via lldb-dev]

>
> > Unless my memory is failing me, I don't think we ever explicitly
> > rejected Rust's language plugin. We removed a few other language
> > plugins (Go, Java) that were not maintained and were becoming an
> > increasing burden on the community. At the same time we agreed that we
> > didn't want to make the same mistake again. Some of the things that
> > come to mind are having a working implementation, testing, CI, etc. If
> > the rust community can show that they're dedicated to maintaining Rust
> > support in LLDB, I wouldn't expect a lot of resistance. I just bring
> > this up because I don't want to discourage anyone from adding support
> > for new languages to LLDB.
>

Do you have any thoughts on how this support should look like?

Realistically, though, I would expect this to go about as well as the
previous two attempts you've mentioned. :(


> >> My tentative proposal is to modify LLDB's DWARFASTParserClang to handle
> DW_TAG_variant et al, and create a C++ approximation of these types, e.g.
> as a polymorphic class, or just an untagged union.   This would provide at
> least a minimal level of functionality for Rust (and possibly other
> languages) and be a much lesser maintenance burden on LLDB core team.
>

I looked at the code in more detail, and unfortunately it looks like C++
AST is not flexible enough to represent variants as polymorphic classes, so
It'll have to be just untagged unions.   But I'd love to hear otherwise
from people more familiar with that code.


> > PS: Are there other changes that live downstream that are not Rust
> > specific and would benefit upstream LLDB and would potentially improve
> > Rust debugging?
>

Nothing major I can think of.  The rest of changes seem to be pretty
Rust-specific.

My general feedback is that it would help a lot if LLDB were less C++- (and
in particular clang-) centric.  For example, right now LLDB converts
various debug info formats directly into clang AST.  As a result, other
languages are forced to re-implement debug info parsing from scratch and
soon as they need to customize anything that cannot be mapped to C/C++
concepts.   There probably needs to be some sort of language-agnostic layer
that abstracts debug info formats for use by language plugins.  If this
layer supported DWARF spec in its entirety, I expect that most languages
would need little to no customization, at least until you get to
implementing a REPL for that language.

A stable ABI for dynamically-loadable language plugins would be the best,
of course.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Rust support in LLDB, again

[Vadim Chugunov via lldb-dev]

Hi Greg,

So if Rust doesn't use clang in its compiler
> - create a new TypeSystem for Rust that would convert DWARF into Rust AST
> types that are native to your Rust compiler that uses as much of the Rust
> compiler sources as possible
> - write a native Rust expression parser which hopefully uses your Rust
> compiler sources to evaluate and run your expression
>

This already exists, but is proving difficult to maintain out-of-tree.  (I
wish that people who modify plugin-related APIs would spend a few minutes
documenting what each of those methods is supposed to do, so plugin
maintainers wouldn't need to reverse-engineer this info!  /rant).


> So the right answer depends on what the Rust community wants. Is the
> language changing rapidly where the debugger must be in sync to take
> advantage and use the latest language features? Or is it stable?
>

Debug info is mostly stable, but over time there will be changes, of
course.  For example, at some point we'll want to change the symbol
mangling scheme.


> The other nice things about creating a new TypeSystem, is that it is a
> plugin and you don't need to compile it in. cmake can be taught to
> conditionally compile in your type system if you want it. It would also
> allow you to have more than one Rust type system if needed for different
> Rust language versions that each could be exclusively compiled in. Having
> your sources be in a new TypeSystem plug-in ensure easy merging when it
> comes to different repositories.
>

Understood.  I just want to point out that implementing a complete type
system plugin just to support one or two type kinds incompatible with C++
is a pretty big burden on language implementors.   If LLDB had a default
"type system" geared towards representing types expressible in DWARF, not
just those found in the C family, it would be usable with other languages
without any custom work, at least until one starts getting into fancy
features like REPL.
It might also serve as an abstraction layer for supporting different debug
info formats.  As I understand, right now, in order to support MS PDB, we'd
need to implement a custom parser for it in addition to the DWARF one?

Let us know about which approach sounds better to the Rust community and we
> can proceed from there!
>

I guess we'd prefer to upstream the Rust plugin.   But I'm not sure how
keep it from breaking without requiring all LLVM devs to install a Rust
compiler...
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Rust support in LLDB, again

[Vadim Chugunov via lldb-dev]

On Fri, Oct 18, 2019 at 10:17 AM Greg Clayton  wrote:

> Yeah this is a tough tradeoff as this is what GDB does or at least did the
> last time I was working on it. In most debuggers, they make up their own
> internal type representation, and have a generic LALR recursive descent
> parser to evaluate single expression statements. This parser must work for
> multiple languages and problems arise when one language has a keyword or
> special operator that others don't have. In the old days, if you wanted to
> call a C++ function in the GDB expression parser you would need to put
> quotes around any qualified names that contained : characters because that
> had been overloaded by the expression parser before C++ to allow getting to
> a static variable in a file ("g_foo:main.c" or "main.c:g_foo"), So you had
> to type '"foo::bar"()' in your expression. The type system tries to avoid
> these issues by allowing each language to define the best functionality for
> each language.
>

Going a bit on a tangent here, but it isn't obvious that a debugger
expression evaluator needs to match full syntax and capabilities of the
source language.  I've been able to get quite a bit of mileage out of a
Python "expression evaluator" on top of a wrapper similar to lldb.value
.  Not
optimal by any stretch, but quite acceptable for baseline experience, IMO.


> One idea is to add rust support in its own TypeSystem and require a cmake
> option to manually enable its compilation. If the cmake flag isn't
> supplied, Rust is not compiled in by default. That way you can upstream it,
> people can try to enable it if any only if they download the rust compiler
> sources. Might be nice to have a rust compiler revision or hash that people
> can/should checkout that is documented in the checked out LLDB sources in
> the Rust type system README. This revision would be the last known good
> revision of the Rust compiler sources they should download in order to
> build the version of Rust that is in LLDB's sources. This way it would not
> break if we had a script in the Rust LLDB sources that knew how to checkout
> the right version of Rust and then users can manually enable Rust. Any rust
> enabled buildbots could ensure the right Rust sources are checked out.
> Maybe you could integrate this with the LLVM mono repo where Rust could be
> a module that can be added so when you add the
> '-DLLVM_ENABLE_PROJECTS="clang;libcxx;lldb;rust"' flag, it would know to
> build the rust bits needed for LLDB?
>

The Rust plugin is written in C++, so Rust compiler source won't be
necessary.  However a binary compiler release would be needed for testing.
It it certainly possible to make Rust support conditional on a cmake flag,
but would it be getting enough (or any) testing if not enabled by default?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

[Vadim Chugunov via lldb-dev]

FWIW, Python provides stable ABI 
for a subset of their API.

I've actually managed to create a version of LLDB that is Python-optional
and Python version-agnostic (for versions 3.3 up).   Though given the
number of hoops I had to jump through to get there, I cannot recommend this
approach for mainline LLDB.


On Fri, Nov 22, 2019 at 9:39 AM Adrian McCarthy via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Yes, I think it's pretty reasonable to expect a specific version of
> Python, especially if the pre-built Python DLLs for Windows are still built
> with versions as old as VS 2013.  Once you get to VS 2015 or 2017, I think
> the compatibility improves.
>
> Perhaps the best thing for the pre-built LLDB is to include the right
> Python DLL in the distro, assuming the licensing allows that.
>
> The more sophisticated solutions are probably more work than is justified
> by the value.
>
> On Fri, Nov 22, 2019 at 8:29 AM Ted Woodward  wrote:
>
>>
>>
>> > > * Dynamically load any supported Python DLL if/when needed
>> > That might be tricky since the different versions are not binary
>> compatible in
>> > general. But it is possible, as Apple folks have shown, though it
>> amounts to
>> > building multiple copies of ScriptInterpreterPython and then choosing
>> the
>> > right one at runtime.
>>
>> It's not just the python dll; it's the modules directory as well. My
>> experiments with different versions of Python on Linux led me to just ship
>> the right python with our distribution.
>>
>> I saw things like building with 2.7.6 but using the 2.7.3 library/modules
>> (and vice versa) would crash, and building with 2.7.6 but running with
>> 2.6.x seemed to be OK, mostly. On Windows, I had crashes when loading
>> Python 2.7.8 from python.org (built with VS 2008) in lldb built with VS
>> 2013, so you have to think about other library dependencies too.
>>
>> My conclusion - you MUST use the same python that lldb was built with.
>> Period.
>>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Setting environment via SBLaunchInfo

[Vadim Chugunov via lldb-dev]

Hi,
I am trying to figure out the proper way of using LLDB's SBLaunchInfo class:
When I launch a process via CLI interpreter, it seems to receive all of the
environment variables inherited from shell, plus the ones I set via
`target.env-vars`:

(lldb) file /usr/bin/env
Current executable set to '/usr/bin/env' (x86_64).
(lldb) set set target.env-vars 'FOO=BAR'
(lldb) run
Process 12733 launched: '/usr/bin/env' (x86_64)
FOO=BAR
GDM_LANG=en_US
CINNAMON_SOFTWARE_RENDERING=1
MUFFIN_NO_SHADOWS=1

Process 12733 exited with status = 0 (0x)

But when I launch via SB API, it looks like only the values explicitly
added to launch_info are passed to the debuggee:

(lldb) script from lldb import *
(lldb) script t = lldb.debugger.CreateTarget('/usr/bin/env')
(lldb) script li = SBLaunchInfo([])
(lldb) script li.SetEnvironmentEntries(['FOO=BAR'], True)
(lldb) script t.Launch(li, SBError())
 >
FOO=BAR
Process 13331 exited with status = 0 (0x)

Is this how it's supposed to work?   If so, I can certainly add all
inherited env vars to launch_info myself, but it isn't clear what to do in
the case of remote debugging, because I couldn't find any way of retrieving
environment from the remote machine.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Setting environment via SBLaunchInfo

[Vadim Chugunov via lldb-dev]

> But I don't think passing lldb's environment variables automatically when
running a remote process is a sensible thing to do - certainly not as the
default anyway.  If the host and target are different OS'es and maybe
different users, etc. lldb's environment may very well not be appropriate
for the target process.

That's what I'm saying - I could not figure out how to correctly launch a
remote application via SB API (other than executing "process launch" via
command interpreter, I suppose).

> Sounds like there should also be an  lldb.eLaunchFlagInheritEnv that
triggers the same behavior from the SB API.

So it's a bug then?


On Mon, Dec 2, 2019 at 2:59 PM Jim Ingham  wrote:

> There's a setting (target.inherit-env) that controls whether "process
> launch" passes its environment variables along with any newly set to the
> process in question.  Sounds like there should also be an
> lldb.eLaunchFlagInheritEnv that triggers the same behavior from the SB API.
>
> But I don't think passing lldb's environment variables automatically when
> running a remote process is a sensible thing to do - certainly not as the
> default anyway.  If the host and target are different OS'es and maybe
> different users, etc. lldb's environment may very well not be appropriate
> for the target process.
>
> JIm
>
>
> > On Nov 26, 2019, at 6:13 PM, Vadim Chugunov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi,
> > I am trying to figure out the proper way of using LLDB's SBLaunchInfo
> class:
> > When I launch a process via CLI interpreter, it seems to receive all of
> the environment variables inherited from shell, plus the ones I set via
> `target.env-vars`:
> >
> > (lldb) file /usr/bin/env
> > Current executable set to '/usr/bin/env' (x86_64).
> > (lldb) set set target.env-vars 'FOO=BAR'
> > (lldb) run
> > Process 12733 launched: '/usr/bin/env' (x86_64)
> > FOO=BAR
> > GDM_LANG=en_US
> > CINNAMON_SOFTWARE_RENDERING=1
> > MUFFIN_NO_SHADOWS=1
> > 
> > Process 12733 exited with status = 0 (0x)
> >
> > But when I launch via SB API, it looks like only the values explicitly
> added to launch_info are passed to the debuggee:
> >
> > (lldb) script from lldb import *
> > (lldb) script t = lldb.debugger.CreateTarget('/usr/bin/env')
> > (lldb) script li = SBLaunchInfo([])
> > (lldb) script li.SetEnvironmentEntries(['FOO=BAR'], True)
> > (lldb) script t.Launch(li, SBError())
> >  0x7fbc674ea0f0> >
> > FOO=BAR
> > Process 13331 exited with status = 0 (0x)
> >
> > Is this how it's supposed to work?   If so, I can certainly add all
> inherited env vars to launch_info myself, but it isn't clear what to do in
> the case of remote debugging, because I couldn't find any way of retrieving
> environment from the remote machine.
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Stackoverflow crash when evaluating an invalid expression

[Vadim Chugunov via lldb-dev]

Looks like I am hitting the same issue.  Was there a fix checked in for
this?

On Thu, Mar 7, 2019 at 3:05 PM Raphael Isemann via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> You can also dump() the AST to a file on disk if that is easier to
> capture than stderr. See the overload of `dump()` that takes a stream:
> https://clang.llvm.org/doxygen/ASTDumper_8cpp_source.html#l00225
>
> - Raphael
>
> Am Do., 7. März 2019 um 19:20 Uhr schrieb Ben Ruthig :
> >
> > Hey Raphael,
> >
> > Yes, you did advise me to drop a D->dumpColor() call in to
> getASTRecordLayout().  For frustrating reasons I still haven't been able to
> capture those logs but when I do I will report back.
> >
> > Thanks so much for your help and quick response!
> >
> > Ben
> >
> > On Thu, Mar 7, 2019 at 12:56 PM Raphael Isemann 
> wrote:
> >>
> >> Hi Ben,
> >>
> >> I think I already answered this last week:
> >> http://lists.llvm.org/pipermail/lldb-dev/2019-February/014789.html
> >>
> >> I don't think you'll get an answer here without posting the
> >> problematic source or giving any more information as I described in my
> >> mail.
> >>
> >> Cheers,
> >> - Raphael
> >>
> >> Am Do., 7. März 2019 um 18:13 Uhr schrieb Ben Ruthig via lldb-dev
> >> :
> >> >
> >> > Hello all,
> >> >
> >> > I am currently investigating an issue where LLDB is crashing due to a
> stack overflow when attempting to evaluate an expression.  I have seen the
> same issue in 6.0.1 and have reproduced it in 7.0.1.  Any help to diagnose
> and fix would be greatly appreciated as I am trying to meet a release
> deadline early next week!
> >> >
> >> > The facts:
> >> > - The expression being evaluated is not a valid expression in the C++
> domain. For example the expression is a datatype like 'Foobar'.  (For
> reasons unexplained I am constrained to supporting this use case.)
> >> > - The crash occurs when using the C++ LLDB API but not when trying to
> evaluate the expression via the LLDB shell or the LLDB Python script
> shell.  However, when doing 'expr Foobar' there is no output and the
> operation is completely silent.  It is similar when trying to do
> 'lldb.frame.EvaluateExpression("Foobar")' in the Python shell as well.  I
> would expect to get some error output or an SbValue in an error state but
> no such luck.
> >> > - I was able to capture a stack trace (attached) and it seems to be a
> recursive loop bottoming out.  For brevity two 'loops' of stacktrace are
> included here:
> >> >
> >> > 3387.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const
> clang::RecordDecl * D) Line 2965C++
> >> > 3388.  liblldb.dll!`anonymous
> namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216C++
> >> > 3389.  liblldb.dll!`anonymous
> namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext &
> Context, const clang::CXXRecordDecl * Class) Line 172C++
> >> > 3390.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const
> clang::RecordDecl * D) Line 2965C++
> >> > 3391.  liblldb.dll!`anonymous
> namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216C++
> >> > 3392.  liblldb.dll!`anonymous
> namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext &
> Context, const clang::CXXRecordDecl * Class) Line 172C++
> >> > 3393.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const
> clang::RecordDecl * D) Line 2965C++
> >> >
> >> > Help please :S
> >> >
> >> > Thanks,
> >> > Ben
> >> >
> >> >
> >> > ___
> >> > lldb-dev mailing list
> >> > lldb-dev@lists.llvm.org
> >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> >
> > --
> > "Sometimes I've believed as many as six impossible things before
> breakfast" - Alice in Wonderland
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB SBAPI questions

[Vadim Chugunov via lldb-dev]

Hi,
I've a couple of questions:

1. Is there a way to get numeric values of C++ template parameters?
SBType has a method for discovering argument kind and type, but I couldn't
find anything for values.

2. Can I enumerate static variables of a class via SBType?  (and read their
values)

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

Re: [lldb-dev] Need help with failing LLDB tests on Windows

[Vadim Chugunov via lldb-dev]

Is there _lldb.pyd in D:\src\llvm\build\ninja_dbg\Lib\site-packages\lldb ?

On Tue, Nov 3, 2020 at 4:53 PM Adrian McCarthy via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> For the past couple weeks, I've been trying to figure out why
> approximately 900+ LLDB tests have been failing for me on my local Windows
> builds.  Bisect turned up nothing--the "good" version that was working for
> me no longer works.  Since nobody else seems to be seeing these failures, I
> suspect it's something environmental.
>
> There are three categories of errors.  I'm currently focused on failures
> that look like this:
>
> FAIL: lldb-api :: lang/objc/unicode-string/TestUnicodeString.py (732 of
>> 2180)
>>  TEST 'lldb-api ::
>> lang/objc/unicode-string/TestUnicodeString.py' FAILED 
>> Script:
>> --
>> C:/Program Files/Python38/python.exe
>> D:/src/llvm/llvm-project/lldb\test\API\dotest.py -S nm -u CXXFLAGS -u
>> CFLAGS --enable-crash-dialog --env
>> LLVM_LIBS_DIR=D:/src/llvm/build/ninja_dbg/./lib --arch x86_64 --build-dir
>> D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex -s
>> D:/src/llvm/build/ninja_dbg/lldb-test-traces --lldb-module-cache-dir
>> D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex/module-cache-lldb\lldb-api
>> --clang-module-cache-dir
>> D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex/module-cache-clang\lldb-api
>> --executable D:/src/llvm/build/ninja_dbg/./bin/lldb.exe --compiler
>> D:/src/llvm/build/ninja_dbg/bin/clang.exe --dsymutil
>> D:/src/llvm/build/ninja_dbg/./bin/dsymutil.exe --filecheck
>> D:/src/llvm/build/ninja_dbg/./bin/FileCheck.exe --yaml2obj
>> D:/src/llvm/build/ninja_dbg/./bin/yaml2obj.exe --lldb-libs-dir
>> D:/src/llvm/build/ninja_dbg/./lib
>> D:\src\llvm\llvm-project\lldb\test\API\lang\objc\unicode-string -p
>> TestUnicodeString.py
>> --
>> Exit Code: 1
>>
>> Command Output (stdout):
>> --
>> lldb version 12.0.0 (https://github.com/llvm/llvm-project.git revision
>> 0fdcd1ae1c988fa19d0c97e9e8678b93a0da)
>>   clang revision 0fdcd1ae1c988fa19d0c97e9e8678b93a0da
>>   llvm revision 0fdcd1ae1c988fa19d0c97e9e8678b93a0da
>>
>> --
>> Command Output (stderr):
>> --
>> Traceback (most recent call last):
>>   File "D:\src\llvm\build\ninja_dbg\Lib\site-packages\lldb\__init__.py",
>> line 35, in 
>> import _lldb
>> ModuleNotFoundError: No module named '_lldb'
>>
>> During handling of the above exception, another exception occurred:
>>
>> Traceback (most recent call last):
>>   File "D:/src/llvm/llvm-project/lldb\test\API\dotest.py", line 7, in
>> 
>> lldbsuite.test.run_suite()
>>   File
>> "D:\src\llvm\llvm-project\lldb\packages\Python\lldbsuite\test\dotest.py",
>> line 874, in run_suite
>> import lldb
>>   File "D:\src\llvm\build\ninja_dbg\Lib\site-packages\lldb\__init__.py",
>> line 38, in 
>> from . import _lldb
>> ImportError: cannot import name '_lldb' from partially initialized module
>> 'lldb' (most likely due to a circular import)
>> (D:\src\llvm\build\ninja_dbg\Lib\site-packages\lldb\__init__.py)
>
>
> It looks like the code in question is generated by Swig (so perhaps it
> depends on the version of Swig?).  The relevant bit seems to be:
>
> try:
>> # Try an absolute import first.  If we're being loaded from lldb,
>> # _lldb should be a built-in module.
>> import _lldb
>> except ImportError:
>> # Relative import should work if we are being loaded by Python.
>> from . import _lldb
>
>
> I don't have much background in Python modules or how Swig produces the
> bindings.  It seems suspicious to me that both import attempts are failing
> (and that we need two).  I'm hoping someone can offer some clues about
> what's going on here and how it's supposed to work.  Is the hint about an
> import cycle relevant or a red herring?
>
> Python 3.8.2
> Swig 3.0.12
>
> Thanks,
> Adrian.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Should MyType's synthetic provider be instantiated for MyType* and MyType** ?

[Vadim Chugunov via lldb-dev]

Hi,
I am observing that if I bind a synthetic provider to MyType, it will also
be instantiated for MyType*, MyType**, etc, and the object passed into the
constructor will be *of the pointer type*.I'd have expected the
synthetic to either not be instantiated for pointers, or to be constructed
on the pointee object directly.

Is this a bug or done this way on purpose?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Should MyType's synthetic provider be instantiated for MyType* and MyType** ?

[Vadim Chugunov via lldb-dev]

On Mon, Jul 19, 2021 at 6:02 PM Jim Ingham  wrote:

> You can control whether you want data-formatters on "class Foo" to also
> match "class Foo *" and "class Foo &" using the --skip-pointers and
> --skip-references options respectively.
> So this part is clearly is by design.
>
> As for what the formatter gets passed, your formatter has chosen to see
> values that are pointers to the type by not passing --skip-pointers, so it
> makes sense to pass it
> the pointer - which it after all asked for.  I can't see a strong enough
> argument either way to want to change the way it currently works, since we
> might break other people's uses of it.
>

Certainly.  I just wish the documentation were more explicit about this
quirk.  This behavior is especially confusing because the single
indirection case usually works, since pointer.GetChildMemberWithName('...')
transparently dereferences.   It starts breaking only at
pointer-to-pointer-to-type.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] 13.0.0-rc1 has been tagged

[Vadim Chugunov via lldb-dev]

Not sure if this is a supported configuration, but I am hitting this error
when compiling on Ubuntu 16.04 with clang 12:

FAILED: /usr/local/bin/clang++  -DGTEST_HAS_RTTI=0 -DHAVE_ROUND
-D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -Itools/lldb/source/Plugins/ABI/ARM
-I/__w/1/s/llvm-project/lldb/source/Plugins/ABI/ARM -Itools/lldb/source
-I/__w/1/s/llvm-project/lldb/include -Itools/lldb/include -Iinclude
-I/__w/1/s/llvm-project/llvm/include
-I/__w/1/python/install/include/python3.9
-I/__w/1/s/llvm-project/llvm/../clang/include -Itools/lldb/../clang/include
-I/__w/1/libxml2/install/include/libxml2
-I/__w/1/s/llvm-project/lldb/source/. -target x86_64-linux-gnu -fPIC -fPIC
-fvisibility-inlines-hidden -Werror=date-time
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
-Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor
-Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment
-Wstring-conversion -Wmisleading-indentation -fdiagnostics-color
-ffunction-sections -fdata-sections -Wno-deprecated-declarations
-Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register
-Wno-vla-extension -Os -DNDEBUG-fno-exceptions -fno-rtti -std=c++14 -MD
-MT
tools/lldb/source/Plugins/ABI/ARM/CMakeFiles/lldbPluginABIARM.dir/ABIMacOSX_arm.cpp.o
-MF
tools/lldb/source/Plugins/ABI/ARM/CMakeFiles/lldbPluginABIARM.dir/ABIMacOSX_arm.cpp.o.d
-o
tools/lldb/source/Plugins/ABI/ARM/CMakeFiles/lldbPluginABIARM.dir/ABIMacOSX_arm.cpp.o
-c /__w/1/s/llvm-project/lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp
In file included from
/__w/1/s/llvm-project/lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp:9:
In file included from
/__w/1/s/llvm-project/lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.h:12:
In file included from
/__w/1/s/llvm-project/lldb/include/lldb/Target/ABI.h:12:
In file included from
/__w/1/s/llvm-project/lldb/include/lldb/Core/PluginInterface.h:12:
In file included from
/__w/1/s/llvm-project/lldb/include/lldb/lldb-private.h:15:
In file included from
/__w/1/s/llvm-project/lldb/include/lldb/lldb-private-enumerations.h:12:
In file included from
/__w/1/s/llvm-project/llvm/include/llvm/ADT/StringRef.h:12:
In file included from
/__w/1/s/llvm-project/llvm/include/llvm/ADT/STLExtras.h:19:
In file included from
/__w/1/s/llvm-project/llvm/include/llvm/ADT/Optional.h:18:
In file included from
/__w/1/s/llvm-project/llvm/include/llvm/ADT/Hashing.h:48:
In file included from
/__w/1/s/llvm-project/llvm/include/llvm/Support/ErrorHandling.h:18:
In file included from
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/string:40:
In file included from
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/char_traits.h:39:
In file included from
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/stl_algobase.h:64:
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/stl_pair.h:134:35:
error: call to implicitly-deleted copy constructor of
'lldb_private::ThreadPlanStack'
: first(std::forward<_U1>(__x)), second(__y) { }
 ^  ~~~
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/ext/new_allocator.h:120:23:
note: in instantiation of function template specialization 'std::pair::pair'
requested here
{ ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
 ^
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/alloc_traits.h:530:8:
note: in instantiation of function template specialization
'__gnu_cxx::new_allocator>::construct, unsigned long &, lldb_private::Thread &>'
requested here
{ __a.construct(__p, std::forward<_Args>(__args)...); }
  ^
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/hashtable_policy.h:1955:28:
note: in instantiation of function template specialization
'std::allocator_traits>>::construct, unsigned long &, lldb_private::Thread &>'
requested here
__value_alloc_traits::construct(__a, __n->_M_valptr(),
  ^
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/hashtable.h:1526:30:
note: in instantiation of function template specialization
'std::__detail::_Hashtable_alloc,
false>>>::_M_allocate_node'
requested here
__node_type* __node =
this->_M_allocate_node(std::forward<_Args>(__args)...);
^
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/hashtable.h:726:11:
note: in instantiation of function template specialization
'std::_Hashtable, std::allocator>, std::__detail::_Select1st,
std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy,
std::__detail::_Hashtable_traits>::_M_emplace' requested here
{ return _M

Re: [lldb-dev] [llvm-dev] 13.0.0-rc1 has been tagged

[Vadim Chugunov via lldb-dev]

Not sure what's up with clang's inclusion chain reporting, but I found a
couple of SO threads [1] [2] regarding the need of the copy constructor:
apparently, until GCC 6, std::unordered_map could not emplace non-copyable
values.  Following the advice in [2], I was able to overcome the error by
rewriting ThreadPlanStack::AddThread like this:
  void AddThread(Thread &thread) {
lldb::tid_t tid = thread.GetID();
m_plans_list.emplace(std::piecewise_construct,
 std::forward_as_tuple(tid),
 std::forward_as_tuple(thread));
  }

[1]:
https://stackoverflow.com/questions/44699545/why-does-stdmap-emplace-need-a-copy-constructor-on-gcc
[2]:
https://stackoverflow.com/questions/27960325/stdmap-emplace-without-copying-val
useue
<https://stackoverflow.com/questions/27960325/stdmap-emplace-without-copying-value>


On Wed, Aug 4, 2021 at 5:10 PM Jim Ingham  wrote:

> That is certainly an odd chain of includes to end up complaining about
> ThreadPlanStacks...
>
> ABIMacOSX.cpp does see the definition of ThreadPlanStacks but not along
> that path...  Something got fairly confused.
>
> There IS an implicitly deleted copy constructor for ThreadPlanStacks, but
> it doesn't get called anywhere.  This is code that is built pretty much
> everywhere and this is the first time I've seen this error.
>
> In the ThreadPlanStack header file, there are a couple of routines the
> iterate over the map of ThreadPlanStacks like (m_plans_list is:
> std::unordered_map):
>
>   void ClearThreadCache() {
> for (auto &plan_list : m_plans_list)
>   plan_list.second.ClearThreadCache();
>   }
>
> But those get "auto &" so they should just be pulling references to
> ThreadPlanStacks out, it shouldn't need to copy them.
>
> And then we do call find on the ThreadPlanStackMap and do something with
> the iterator returned:
>
>   bool RemoveTID(lldb::tid_t tid) {
> auto result = m_plans_list.find(tid);
> if (result == m_plans_list.end())
>   return false;
> result->second.ThreadDestroyed(nullptr);
> m_plans_list.erase(result);
> return true;
>   }
>
> But the iterator of a map shouldn't require a copy of the value, that
> doesn't make sense.
>
> Other than that, I can't see anything funny here.
>
> Is this something triggered by -pedantic?
>
> Jim
>
>
> > On Aug 4, 2021, at 4:22 PM, Vadim Chugunov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Not sure if this is a supported configuration, but I am hitting this
> error when compiling on Ubuntu 16.04 with clang 12:
> >
> > FAILED: /usr/local/bin/clang++  -DGTEST_HAS_RTTI=0 -DHAVE_ROUND
> -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
> -D__STDC_LIMIT_MACROS -Itools/lldb/source/Plugins/ABI/ARM
> -I/__w/1/s/llvm-project/lldb/source/Plugins/ABI/ARM -Itools/lldb/source
> -I/__w/1/s/llvm-project/lldb/include -Itools/lldb/include -Iinclude
> -I/__w/1/s/llvm-project/llvm/include
> -I/__w/1/python/install/include/python3.9
> -I/__w/1/s/llvm-project/llvm/../clang/include -Itools/lldb/../clang/include
> -I/__w/1/libxml2/install/include/libxml2
> -I/__w/1/s/llvm-project/lldb/source/. -target x86_64-linux-gnu -fPIC -fPIC
> -fvisibility-inlines-hidden -Werror=date-time
> -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter
> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
> -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough
> -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor
> -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment
> -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color
> -ffunction-sections -fdata-sections -Wno-deprecated-declarations
> -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register
> -Wno-vla-extension -Os -DNDEBUG-fno-exceptions -fno-rtti -std=c++14 -MD
> -MT
> tools/lldb/source/Plugins/ABI/ARM/CMakeFiles/lldbPluginABIARM.dir/ABIMacOSX_arm.cpp.o
> -MF
> tools/lldb/source/Plugins/ABI/ARM/CMakeFiles/lldbPluginABIARM.dir/ABIMacOSX_arm.cpp.o.d
> -o
> tools/lldb/source/Plugins/ABI/ARM/CMakeFiles/lldbPluginABIARM.dir/ABIMacOSX_arm.cpp.o
> -c /__w/1/s/llvm-project/lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp
> > In file included from
> /__w/1/s/llvm-project/lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp:9:
> > In file included from
> /__w/1/s/llvm-project/lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.h:12:
> > In file included from
> /__w/1/s/llvm-project/lldb/include/lldb/Target/ABI.h:12:
> > In file included from
> /__w/1/s/llvm-project/lldb/include/lldb/Core/PluginInterface.h:12:
> > In file included from
> /__w/1/s/llvm-project/lldb/in