[lldb-dev] [Bug 31571] lldb 3.8, 3.9 and 4.0 hang on Debian because of the classic "registered more than once" with lldb-server

[via lldb-dev]

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

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|lldb-dev@lists.llvm.org |lab...@google.com

--- Comment #2 from lab...@google.com ---
Created attachment 17819
  --> https://llvm.org/bugs/attachment.cgi?id=17819&action=edit
proposed patch

Can you try whether the attached patch fixes the problem.

It's a bit of a hack, but given the current state of lldb's dependencies, I
think it's the best I can do at the moment.

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

Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on Linux Ubuntu 16.04

[Pavel Labath via lldb-dev]

Nice catch. I think this backtrace should be enough to bring the problem to
the attention of the kernel developers. Have you tried contacting them
already? I can help you with that if you want.

On 6 January 2017 at 23:34, Eugene Birukov  wrote:

> Hi,
>
>
> It seems the problem is related to transparent huge pages. Disabling them
> helps.
>
>
> The LLDB spins in this code:
>
>
> [11428.634820] Call Trace:
> [11428.634821]  [] do_huge_pmd_wp_page+0x62e/0xb80
> [11428.634822]  [] handle_mm_fault+0x705/0xfe0
> [11428.634823]  [] ? follow_page_mask+0x37d/0x7a0
> [11428.634824]  [] __get_user_pages+0x19b/0x660
> [11428.634825]  [] get_user_pages+0x52/0x60
> [11428.634825]  [] __access_remote_vm+0xcb/0x1f0
> [11428.634826]  [] access_process_vm+0x50/0x70
> [11428.634827]  [] ptrace_request+0x2da/0x620
> [11428.634828]  [] ? wait_task_inactive+0x16c/0x1f0
> [11428.634829]  [] arch_ptrace+0x29b/0x300
> [11428.634830]  [] SyS_ptrace+0xbe/0x110
> [11428.634831]  [] system_call_fastpath+0x16/0x1b
>
> Eugene
>
>
> Sent from Outlook 
>
>
> --
> *From:* Pavel Labath 
> *Sent:* Tuesday, December 13, 2016 1:39 AM
>
> *To:* Eugene Birukov
> *Subject:* Re: [lldb-dev] Lldb-server spins forever in ptrace with 100%
> CPU on Linux Ubuntu 16.04
>
> Yeah, we support a couple of communication transports. For example, you
> can switch to using unix sockets instead. It's easiest if you just connect
> the server and client manually (for automatically starting up the server
> you would have to edit the source, I think.)
>
> $ bin/lldb-server gdbserver unix-abstract:///tmp/X -- /bin/ls
>
> $ bin/lldb
> (lldb) process connect unix-abstract-connect:///tmp/X
> Process 21731 stopped
> * thread #1, name = 'ls', stop reason = signal SIGSTOP
> frame #0: 0x7f4b341bb2d0
> ->  0x7f4b341bb2d0: movq   %rsp, %rdi
> 0x7f4b341bb2d3: callq  0x7f4b341bea40
> 0x7f4b341bb2d8: movq   %rax, %r12
> 0x7f4b341bb2db: movl   0x221b17(%rip), %eax
>
>
> Good luck. Let me know what you find out.
> pl
>
>
> On 12 December 2016 at 18:11, Eugene Birukov  wrote:
>
>> OK, thanks!
>>
>> I'll work on getting reliable repro on something I can attach kgdb to.
>>
>>
>> Meanwhile - is there any options in lldb-server communication protocol I
>> could play with? Say, using pipe instead of tcp/ip or vice versa?
>>
>>
>> Sent from Outlook 
>>
>>
>> --
>> *From:* Pavel Labath 
>> *Sent:* Friday, December 9, 2016 2:56 AM
>>
>> *To:* Eugene Birukov
>> *Subject:* Re: [lldb-dev] Lldb-server spins forever in ptrace with 100%
>> CPU on Linux Ubuntu 16.04
>>
>> It looks like debugging this remotely will not lead anywhere. I don't
>> think I have enough knowledge about the kernel to help you with that. If I
>> were able to reproduce it myself, maybe I'd get somewhere by random
>> experiments, but doing it over the email is too slow. :)
>>
>> I suggest you ask some of the kernel developers about it. They should be
>> able to direct you where to look further, and may be aware of kernel
>> changes between the two versions that would affect this.
>>
>> cheers,
>> pl
>>
>> On 8 December 2016 at 17:12, Eugene Birukov  wrote:
>>
>>> *> **From your description is sounds like un-predicability comes from
>>> the tracee side*
>>>
>>>
>>> Not exactly. If problem is there, it repro's 100%. Things that affect
>>> repro - make it go away or shift to different address:
>>>
>>>
>>>
>>>1. Delays in the client. If I put ::sleep(0) right after sending
>>>write memory request (not sure - are we writing in pipe or in socket?) - 
>>> it
>>>might kill repro.
>>>2. Changes in VM. Copying all bits into would be identical VM hurts
>>>repro.
>>>3. Changes in the target application. I assume this is mainly layout
>>>of different VMA that shift after significant code change because target 
>>> is
>>>fully stopped and it is hard to believe that the contents of the memory
>>>matters... Just in case - I tried to write different values and change
>>>write size to 8 (not to trigger the recursion in llldb-server).
>>>
>>> Things that do not matter:
>>>
>>>
>>>- Delays in the server. As soon as we are about to call ptrace, no
>>>amount of delays caused by stepping, etc. matters, the damage is already
>>>there.
>>>
>>> So, it seems that the problem is really not in ptrace but in the
>>> communication channel between the client and the server. Ptrace looks
>>> like just an innocent bystander caught in the gang crossfire on the street.
>>>
>>>
>>> BTW, I am on short vacation, will be back on Monday 12/12.
>>>
>>>
>>> Sent from Outlook 
>>>
>>>
>>> --
>>> *From:* Pavel Labath 
>>> *Sent:* Thursday, December 8, 2016 3:19 AM
>>> *To:* Eugene Birukov
>>>
>>> *Subject:* Re: [lldb-dev] Lldb-server spins forever in ptrace with 100%
>>> CPU on Linux Ubuntu 16.04
>>>
>>> Thanks for the info. I agree with

Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on Linux Ubuntu 16.04

[Eugene Birukov via lldb-dev]

Yes, we have contacted RHEL people. It repros there too.


Sent from Outlook



From: Pavel Labath 
Sent: Monday, January 9, 2017 2:53 AM
To: Eugene Birukov
Cc: LLDB
Subject: Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on 
Linux Ubuntu 16.04

Nice catch. I think this backtrace should be enough to bring the problem to the 
attention of the kernel developers. Have you tried contacting them already? I 
can help you with that if you want.

On 6 January 2017 at 23:34, Eugene Birukov 
mailto:eugen...@hotmail.com>> wrote:

Hi,


It seems the problem is related to transparent huge pages. Disabling them helps.


The LLDB spins in this code:


[11428.634820] Call Trace:
[11428.634821]  [] do_huge_pmd_wp_page+0x62e/0xb80
[11428.634822]  [] handle_mm_fault+0x705/0xfe0
[11428.634823]  [] ? follow_page_mask+0x37d/0x7a0
[11428.634824]  [] __get_user_pages+0x19b/0x660
[11428.634825]  [] get_user_pages+0x52/0x60
[11428.634825]  [] __access_remote_vm+0xcb/0x1f0
[11428.634826]  [] access_process_vm+0x50/0x70
[11428.634827]  [] ptrace_request+0x2da/0x620
[11428.634828]  [] ? wait_task_inactive+0x16c/0x1f0
[11428.634829]  [] arch_ptrace+0x29b/0x300
[11428.634830]  [] SyS_ptrace+0xbe/0x110
[11428.634831]  [] system_call_fastpath+0x16/0x1b

Eugene


Sent from Outlook



From: Pavel Labath mailto:lab...@google.com>>
Sent: Tuesday, December 13, 2016 1:39 AM

To: Eugene Birukov
Subject: Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on 
Linux Ubuntu 16.04

Yeah, we support a couple of communication transports. For example, you can 
switch to using unix sockets instead. It's easiest if you just connect the 
server and client manually (for automatically starting up the server you would 
have to edit the source, I think.)

$ bin/lldb-server gdbserver unix-abstract:///tmp/X -- /bin/ls

$ bin/lldb
(lldb) process connect unix-abstract-connect:///tmp/X
Process 21731 stopped
* thread #1, name = 'ls', stop reason = signal SIGSTOP
frame #0: 0x7f4b341bb2d0
->  0x7f4b341bb2d0: movq   %rsp, %rdi
0x7f4b341bb2d3: callq  0x7f4b341bea40
0x7f4b341bb2d8: movq   %rax, %r12
0x7f4b341bb2db: movl   0x221b17(%rip), %eax


Good luck. Let me know what you find out.
pl


On 12 December 2016 at 18:11, Eugene Birukov 
mailto:eugen...@hotmail.com>> wrote:

OK, thanks!

I'll work on getting reliable repro on something I can attach kgdb to.


Meanwhile - is there any options in lldb-server communication protocol I could 
play with? Say, using pipe instead of tcp/ip or vice versa?


Sent from Outlook



From: Pavel Labath mailto:lab...@google.com>>
Sent: Friday, December 9, 2016 2:56 AM

To: Eugene Birukov
Subject: Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on 
Linux Ubuntu 16.04

It looks like debugging this remotely will not lead anywhere. I don't think I 
have enough knowledge about the kernel to help you with that. If I were able to 
reproduce it myself, maybe I'd get somewhere by random experiments, but doing 
it over the email is too slow. :)

I suggest you ask some of the kernel developers about it. They should be able 
to direct you where to look further, and may be aware of kernel changes between 
the two versions that would affect this.

cheers,
pl

On 8 December 2016 at 17:12, Eugene Birukov 
mailto:eugen...@hotmail.com>> wrote:

> From your description is sounds like un-predicability comes from the tracee 
> side


Not exactly. If problem is there, it repro's 100%. Things that affect repro - 
make it go away or shift to different address:


  1.  Delays in the client. If I put ::sleep(0) right after sending write 
memory request (not sure - are we writing in pipe or in socket?) - it might 
kill repro.
  2.  Changes in VM. Copying all bits into would be identical VM hurts repro.
  3.  Changes in the target application. I assume this is mainly layout of 
different VMA that shift after significant code change because target is fully 
stopped and it is hard to believe that the contents of the memory matters... 
Just in case - I tried to write different values and change write size to 8 
(not to trigger the recursion in llldb-server).

Things that do not matter:

  *   Delays in the server. As soon as we are about to call ptrace, no amount 
of delays caused by stepping, etc. matters, the damage is already there.

So, it seems that the problem is really not in ptrace but in the communication 
channel between the client and the server. Ptrace looks like just an innocent 
bystander caught in the gang crossfire on the street.


BTW, I am on short vacation, will be back on Monday 12/12.


Sent from Outlook



From: Pavel Labath mailto:lab...@google.com>>
Sent: Thursday, December 8, 2016 3:19 AM
To: Eugene Birukov

Subject: Re: [lldb-dev] Lldb-server spins

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

[Jeffrey Tan via lldb-dev]

Hi,

O ur company is using Buck(https://buckbuild.com/) to build internal
service. Recently the build team made a change in buck to not merge dwarf
symbols from each object file into final binary so debugger needs to read
source/symbol table from compilation unit itself.
This seems to break the lldb in various aspect:
1. Setting source line breakpoint in library files are not working
2. Callstack did not show the source location well for library frame

I tried latest lldb which this bug still reproduces. Here is the logging
for it:
(lldb) b TaoDataLayer.cpp:50
Target::AddBreakpoint (internal = no) => break_id = 6: file =
'TaoDataLayer.cpp', line = 50, exact_match = 0
*error: Unable to set breakpoint for TaoDataLayer.cpp:50  at file address
0x*
Breakpoint 6: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.


My debugging shows the Address::IsValid() returns false for line start
symbol here because it's file address is 0x:
https://github.com/llvm-mirror/lldb/blob/ceb5f6cd339a4bcd49666158578f883c1ec96663/source/Breakpoint/BreakpointResolver.cpp#L263

It seems that, after locating the symbol for the line_entry, the code below
did not update sc.line_entry pointing to the original line_entry so it
contains the uninitialized 0x value which will fail the
isValid() check later:
https://github.com/llvm-mirror/lldb/blob/26fea9dbbeb3020791cdbc46fbf3cc9d7685d7fd/source/Symbol/CompileUnit.cpp#L375

I tried to fix this by doing "sc.line_entry = line_entry;" before
both resolve_scope branches. This seems to fix the breakpoint but the
callstack and source locator still can't locate the source file correctly
while hitting the breakpoint.

Questions:
1. Is this a known issue? If so, is there any existing fix I can port?
2. If not, does my investigation above sound reasonable? Any
suggestion/direction for callstack and source locator part of fix?

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

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

[Greg Clayton via lldb-dev]

Comments below.

> On Jan 9, 2017, at 1:10 PM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> Hi,
> 
> O ur company is using Buck(https://buckbuild.com/ ) 
> to build internal service. Recently the build team made a change in buck to 
> not merge dwarf symbols from each object file into final binary so debugger 
> needs to read source/symbol table from compilation unit itself.

How are debug symbols expected to be found? Is fission being used where the 
DWARF for each compile unit is in .dwo files and the main executable has 
skeleton DWARF? I will skip all other questions until we know more about how 
and where the DWARF is.

Greg Clayton

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

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

[Jeffrey Tan via lldb-dev]

Hey Greg, I just confirmed this with our build team. I seem to have
misunderstood the location of debug symbol. It is actually not inside each
individual object file but:

The debug info in dev mode sits in the .debug_* sections of the shared
libraries (we don't use debug fission).

One potential complicating factor is that we relativize the
DW_AT_comp_dirattributes
in the DWARF info, so that it's almost always just a long reference to the
current working directory (e.g. .///).


I do not know why this(symbol in shared library) would cause the bug though.


Jeffrey

On Mon, Jan 9, 2017 at 1:57 PM, Greg Clayton  wrote:

> Comments below.
>
> On Jan 9, 2017, at 1:10 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi,
>
> O ur company is using Buck(https://buckbuild.com/) to build internal
> service. Recently the build team made a change in buck to not merge dwarf
> symbols from each object file into final binary so debugger needs to read
> source/symbol table from compilation unit itself.
>
>
> How are debug symbols expected to be found? Is fission being used where
> the DWARF for each compile unit is in .dwo files and the main executable
> has skeleton DWARF? I will skip all other questions until we know more
> about how and where the DWARF is.
>
> Greg Clayton
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Hans Wennborg via lldb-dev]

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] LLDB failed to locate source when dwarf symbols are inside compile unit on Linux

[Greg Clayton via lldb-dev]

In ELF files if there is a section named “.gnu_debuglink” it will contain a 
path to the external debug file. Dump this section and see what it contains. 
This section contains a null terminated C string as the path followed by a 4 
byte aligned 32 bit integer which is a file CRC. Check to see the path is 
relative.

I am guessing this is your problem.

Greg


> On Jan 9, 2017, at 3:42 PM, Jeffrey Tan  wrote:
> 
> Hey Greg, I just confirmed this with our build team. I seem to have 
> misunderstood the location of debug symbol. It is actually not inside each 
> individual object file but:
> The debug info in dev mode sits in the .debug_* sections of the shared 
> libraries (we don't use debug fission).
> One potential complicating factor is that we relativize the 
> DW_AT_comp_dirattributes in the DWARF info, so that it's almost always just a 
> long reference to the current working directory (e.g. .///).
> 
> I do not know why this(symbol in shared library) would cause the bug though.
> 
> Jeffrey
> 
> On Mon, Jan 9, 2017 at 1:57 PM, Greg Clayton  > wrote:
> Comments below.
> 
>> On Jan 9, 2017, at 1:10 PM, Jeffrey Tan via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> Hi,
>> 
>> O ur company is using Buck(https://buckbuild.com/ ) 
>> to build internal service. Recently the build team made a change in buck to 
>> not merge dwarf symbols from each object file into final binary so debugger 
>> needs to read source/symbol table from compilation unit itself.
> 
> How are debug symbols expected to be found? Is fission being used where the 
> DWARF for each compile unit is in .dwo files and the main executable has 
> skeleton DWARF? I will skip all other questions until we know more about how 
> and where the DWARF is.
> 
> Greg Clayton
> 
> 

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

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