Re: [lldb-dev] [cfe-dev] [llvm-dev] Should we stop supporting building with Visual Studio?

[Chris Bieneman via lldb-dev]

I don't personally use the Xcode generator, but I know lots of people who do. 
The Xcode generator can generate a working Xcode project with an accurate clang 
index. One of the challenges to get that working though is that the project 
actually has to be able to build at least through intrinsics_gen, otherwise 
there are headers missing and the indexing falls over. I assume Visual Studio's 
intellisense also requires building through header generation for its indexing 
to work correctly.

Similar to MSBuild, Xcodebuild is *way* slower at building LLVM than ninja, so 
I think many Xcode users are already using a workflow similar to what Zachary 
described in his initial email, but I know people also run the test targets 
from Xcode.

Since the benefit of dropping support for building/testing with Visual studio 
would basically be moot without also dropping support for building/testing with 
Xcode I'm really not in favor of this.

I do think that the VS native CMake integration is promising, but it has a long 
way to come before it will really replace the native project generator. I've 
been using it when I use Windows (which admittedly isn't very often), and have 
found it to build well, but the UI is unwieldy, and it has problems with the 
number of build targets that LLVM's ninja build produces.

-Chris


> On Oct 10, 2018, at 9:40 AM, Danila Malyutin via cfe-dev 
>  wrote:
> 
> Have anyone had any experience with VS native CMake integration? You don’t 
> need to employ all the described hacks when you can just trigger Ninja build 
> from VS itself. I’ve used CMake + Ninja from VS on a couple smaller projects 
> without any problems. It was very smooth. But it might not be the case for 
> something as big and complicated as LLVM. I remember trying to use CMake 
> project about a year ago but in the end I’ve decided to stick with .sln . I 
> don’t recall whether there were some show stopping bugs, if it was generally 
> worse experience or something else. Also, the situation has probably changed 
> for the better since then. If not, perhaps that’s something LLVM could 
> improve from its side.
>  
> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of Nicolas 
> Capens via llvm-dev
> Sent: Wednesday, October 10, 2018 17:16
> To: ztur...@google.com
> Cc: llvm-...@lists.llvm.org; cfe-...@lists.llvm.org; lldb-dev@lists.llvm.org
> Subject: Re: [llvm-dev] Should we stop supporting building with Visual Studio?
>  
> Hi Zachary,
>  
> We use LLVM JIT in SwiftShader, which is used by Google Chrome and Android 
> (Emulator). Most development takes place in Visual Studio, where it builds as 
> part of the rest of the SwiftShader solution. So we care about LLVM source 
> files compiling successfully within Visual Studio.
>  
> Would it be reasonable to at least ensure that major releases (7.0, 8.0, 
> etc.) build with Visual Studio? We don't care much about breakages in between 
> releases, and the other issues you listed don't affect us much either due to 
> using custom solution/project files.
>  
> Thanks for your consideration,
> Nicolas Capens
>  
> On Sun, Oct 7, 2018 at 4:51 PM Zachary Turner via llvm-dev 
> mailto:llvm-...@lists.llvm.org>> wrote:
> This has been on my mind for quite some time, but recently it's been popping 
> up more and more seeing some of the issues people have run into.
>  
> Before people get the wrong idea, let me make one thing clear.  **I am not 
> proposing we stop supporting the CMake Visual Studio generator.  I am only 
> proposing we stop supporting actually compiling with the generated project**. 
>  Yes the distinction is important, and I'll elaborate more on why later.  
> First though, here are some of the issues with the VS generator:
>  
> 1) Using MSBuild is slower than Ninja.
> 2) Unless you remember to pass -Thost=x64 on the command line, you won't be 
> able to successfully build.  We can (and have) updated the documentation to 
> indicate this, but it's not intuitive and still bites people because for some 
> reason this is not the default.
> 3) Even if you do pass -Thost=x64 to CMake, it will apparently still fail 
> sometimes.  See this thread for details: 
> http://lists.llvm.org/pipermail/cfe-dev/2018-October/059609.html 
> .
>   It seems the parallel build scheduler does not do a good job and can bring 
> a machine down.  This is not the first time though, every couple of months 
> there's a thread about how building or running tests from within VS doesn't 
> work.
> 4) Supporting it is a continuous source of errors and mistakes when writing 
> tests.  The VS generator outputs a project which can build Debug / Release 
> with a single project.  This means that `CM

Re: [lldb-dev] Remote debugging ARM target from x86 host

[Chris Bieneman via lldb-dev]

I committed a fix in r312008. Please test it to verify that it resolves your 
issue.

Thanks,
-Chris

> On Aug 28, 2017, at 8:41 PM, Ramana  wrote:
> 
> Thank you, Chris. Looking forward to the patch.
> 
> On Tue, Aug 29, 2017 at 1:28 AM, Chris Bieneman  wrote:
>> I had a chance to look into this more, and I found a bug in the listen 
>> behavior. I'm testing a solution to it now. Will post it if it resolves the 
>> issue.
>> 
>> -Chris
>> 
>>> On Aug 25, 2017, at 10:36 AM, Greg Clayton via lldb-dev 
>>>  wrote:
>>> 
>>> Maybe we can make it open only an IPv4 socket for lldb-server for now as a 
>>> work around?
>>> 
 On Aug 25, 2017, at 8:47 AM, Chris Bieneman  wrote:
 
 Since lldb-server only supports running on a limited set of host operating 
 systems it is hard for me to diagnose the issue completely, but I suspect 
 the problem is caused by the fact that the new listening code can open 
 more than one socket, and TCPSocket::GetLocalPortNumber() may be 
 misbehaving.
 
 I'm unlikely to have time to investigate further until next week, but it 
 should be possible to craft a unit test that verifies that 
 GetLocalPortNumber() returns non-zero on a socket that is listening before 
 a connection is established. That might reproduce the issue in a more easy 
 to debug environment.
 
 -Chris
 
> On Aug 25, 2017, at 7:38 AM, Ramana via lldb-dev 
>  wrote:
> 
> Ted, Greg,
> 
> I have built lldb tools @r300578 and the lldb-server is returning the
> proper port number to lldb client and the remote debugging is working.
> I have given the lldb-server log at the bottom of my reply.
> 
> So, it looks https://reviews.llvm.org/rL300579 (Update LLDB Host to
> support IPv6 over TCP) is causing the issue.
> 
>> Ramana, can you stick in a log message to print port_cstr? I suspect 
>> it's actually getting 0 back from lldb-server, which would tell us the 
>> error is in the server code, not the client code.
> 
> Ted, I did that and actually the pipe read is returning zero port
> number. So definitely the issue is on the server side.
> 
>  GDBRemoteCommunication::StartDebugserverProcess() port_cstr
> before socket pipe read
>  GDBRemoteCommunication::StartDebugserverProcess() port_cstr after
> socket pipe read
> 
> 
>> Ted's comments are correct and I am guessing we will find the 
>> "lldb-server gdb-server" is not doing the right thing and it isn't 
>> returning the correctly bound port.
>> 
>> When we are doing remote stuff we must use TCP so there should be 
>> lldb-server should be opening a TCP socket, binding, listening and 
>> accepting a connection from the remote LLDB.
>> 
>> Greg
> 
> Greg, thanks for the comments. Are you saying I should check what is
> happening on the TCP socket side? How do I do it other than walking
> through the code?
> 
> 
> root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb-server platform
> --log-file Ramana/remote.log --log-channels "gdb-remote process"
> --server --listen *:1400
> Connection established.
> error: lost connection
> lldb-server exiting...
> ^C
> root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb --version
> lldb version 5.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk
> revision 300578)
> clang revision 300578
> llvm revision 300578
> root@arria5:~# cat Ramana/remote.log
> GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0, 
> port=0)
> GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote
> stub exe '/mnt/var/patch_bins/binaries/bin/lldb-server'
> launch info for gdb-remote stub:
> Executable: lldb-server
> Triple: *-*-*
> Arguments:
> argv[0]="/mnt/var/patch_bins/binaries/bin/lldb-server"
> argv[1]="gdbserver"
> argv[2]="tcp://10.10.12.3:0"
> argv[3]="--native-regs"
> argv[4]="--pipe"
> argv[5]="7"
> argv[6]=NULL
> 
> Environment:
> env[0]="XDG_SESSION_ID=c7"
> env[1]="TERM=xterm-256color"
> env[2]="SHELL=/bin/sh"
> env[3]="SSH_CLIENT=172.16.16.51 40072 22"
> env[4]="SSH_TTY=/dev/pts/0"
> env[5]="USER=root"
> env[6]="MAIL=/var/mail/root"
> env[7]="PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin"
> env[8]="PWD=/home/root"
> env[9]="EDITOR=vi"
> env[10]="PS1=\u@\h:\w\$ "
> env[11]="SHLVL=1"
> env[12]="HOME=/home/root"
> env[13]="LOGNAME=root"
> env[14]="SSH_CONNECTION=172.16.16.51 40072 10.10.2.4 22"
> env[15]="XDG_RUNTIME_DIR=/run/user/0"
> env[16]="_=/mnt/var/patch_bins/binaries/bin/lldb-server"
> env[17]=NULL
> 
> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 
> 48039 port
> 
> 
> Regards,
> Ramana
> 
> On Thu, Aug 24, 2017 at 10:10 PM, Greg C

Re: [lldb-dev] Remote debugging ARM target from x86 host

[Chris Bieneman via lldb-dev]

I had a chance to look into this more, and I found a bug in the listen 
behavior. I'm testing a solution to it now. Will post it if it resolves the 
issue.

-Chris

> On Aug 25, 2017, at 10:36 AM, Greg Clayton via lldb-dev 
>  wrote:
> 
> Maybe we can make it open only an IPv4 socket for lldb-server for now as a 
> work around?
> 
>> On Aug 25, 2017, at 8:47 AM, Chris Bieneman  wrote:
>> 
>> Since lldb-server only supports running on a limited set of host operating 
>> systems it is hard for me to diagnose the issue completely, but I suspect 
>> the problem is caused by the fact that the new listening code can open more 
>> than one socket, and TCPSocket::GetLocalPortNumber() may be misbehaving.
>> 
>> I'm unlikely to have time to investigate further until next week, but it 
>> should be possible to craft a unit test that verifies that 
>> GetLocalPortNumber() returns non-zero on a socket that is listening before a 
>> connection is established. That might reproduce the issue in a more easy to 
>> debug environment.
>> 
>> -Chris
>> 
>>> On Aug 25, 2017, at 7:38 AM, Ramana via lldb-dev  
>>> wrote:
>>> 
>>> Ted, Greg,
>>> 
>>> I have built lldb tools @r300578 and the lldb-server is returning the
>>> proper port number to lldb client and the remote debugging is working.
>>> I have given the lldb-server log at the bottom of my reply.
>>> 
>>> So, it looks https://reviews.llvm.org/rL300579 (Update LLDB Host to
>>> support IPv6 over TCP) is causing the issue.
>>> 
 Ramana, can you stick in a log message to print port_cstr? I suspect it's 
 actually getting 0 back from lldb-server, which would tell us the error is 
 in the server code, not the client code.
>>> 
>>> Ted, I did that and actually the pipe read is returning zero port
>>> number. So definitely the issue is on the server side.
>>> 
>>>   GDBRemoteCommunication::StartDebugserverProcess() port_cstr
>>> before socket pipe read
>>>   GDBRemoteCommunication::StartDebugserverProcess() port_cstr after
>>> socket pipe read
>>> 
>>> 
 Ted's comments are correct and I am guessing we will find the "lldb-server 
 gdb-server" is not doing the right thing and it isn't returning the 
 correctly bound port.
 
 When we are doing remote stuff we must use TCP so there should be 
 lldb-server should be opening a TCP socket, binding, listening and 
 accepting a connection from the remote LLDB.
 
 Greg
>>> 
>>> Greg, thanks for the comments. Are you saying I should check what is
>>> happening on the TCP socket side? How do I do it other than walking
>>> through the code?
>>> 
>>> 
>>> root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb-server platform
>>> --log-file Ramana/remote.log --log-channels "gdb-remote process"
>>> --server --listen *:1400
>>> Connection established.
>>> error: lost connection
>>> lldb-server exiting...
>>> ^C
>>> root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb --version
>>> lldb version 5.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk
>>> revision 300578)
>>> clang revision 300578
>>> llvm revision 300578
>>> root@arria5:~# cat Ramana/remote.log
>>> GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0, 
>>> port=0)
>>> GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote
>>> stub exe '/mnt/var/patch_bins/binaries/bin/lldb-server'
>>> launch info for gdb-remote stub:
>>> Executable: lldb-server
>>> Triple: *-*-*
>>> Arguments:
>>> argv[0]="/mnt/var/patch_bins/binaries/bin/lldb-server"
>>> argv[1]="gdbserver"
>>> argv[2]="tcp://10.10.12.3:0"
>>> argv[3]="--native-regs"
>>> argv[4]="--pipe"
>>> argv[5]="7"
>>> argv[6]=NULL
>>> 
>>> Environment:
>>> env[0]="XDG_SESSION_ID=c7"
>>> env[1]="TERM=xterm-256color"
>>> env[2]="SHELL=/bin/sh"
>>> env[3]="SSH_CLIENT=172.16.16.51 40072 22"
>>> env[4]="SSH_TTY=/dev/pts/0"
>>> env[5]="USER=root"
>>> env[6]="MAIL=/var/mail/root"
>>> env[7]="PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin"
>>> env[8]="PWD=/home/root"
>>> env[9]="EDITOR=vi"
>>> env[10]="PS1=\u@\h:\w\$ "
>>> env[11]="SHLVL=1"
>>> env[12]="HOME=/home/root"
>>> env[13]="LOGNAME=root"
>>> env[14]="SSH_CONNECTION=172.16.16.51 40072 10.10.2.4 22"
>>> env[15]="XDG_RUNTIME_DIR=/run/user/0"
>>> env[16]="_=/mnt/var/patch_bins/binaries/bin/lldb-server"
>>> env[17]=NULL
>>> 
>>> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 48039 
>>> port
>>> 
>>> 
>>> Regards,
>>> Ramana
>>> 
>>> On Thu, Aug 24, 2017 at 10:10 PM, Greg Clayton  wrote:
 
> On Aug 24, 2017, at 8:33 AM, Ted Woodward  
> wrote:
> 
> The lldb-server launch line looks ok; it should take the port 0 arg and 
> get a port from the OS.
> lldb is getting the port back from lldb-server in 4.0.1, as seen here:
> 
>> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 
>> 56543 port
> 
> But for 5.0.0 we see it fail the debugserver launch, and get:
> 
>> GDBRemoteCommunication::StartDebugserverProcess() d

Re: [lldb-dev] Remote debugging ARM target from x86 host

[Chris Bieneman via lldb-dev]

Since lldb-server only supports running on a limited set of host operating 
systems it is hard for me to diagnose the issue completely, but I suspect the 
problem is caused by the fact that the new listening code can open more than 
one socket, and TCPSocket::GetLocalPortNumber() may be misbehaving.

I'm unlikely to have time to investigate further until next week, but it should 
be possible to craft a unit test that verifies that GetLocalPortNumber() 
returns non-zero on a socket that is listening before a connection is 
established. That might reproduce the issue in a more easy to debug environment.

-Chris

> On Aug 25, 2017, at 7:38 AM, Ramana via lldb-dev  
> wrote:
> 
> Ted, Greg,
> 
> I have built lldb tools @r300578 and the lldb-server is returning the
> proper port number to lldb client and the remote debugging is working.
> I have given the lldb-server log at the bottom of my reply.
> 
> So, it looks https://reviews.llvm.org/rL300579 (Update LLDB Host to
> support IPv6 over TCP) is causing the issue.
> 
>> Ramana, can you stick in a log message to print port_cstr? I suspect it's 
>> actually getting 0 back from lldb-server, which would tell us the error is 
>> in the server code, not the client code.
> 
> Ted, I did that and actually the pipe read is returning zero port
> number. So definitely the issue is on the server side.
> 
> GDBRemoteCommunication::StartDebugserverProcess() port_cstr
> before socket pipe read
> GDBRemoteCommunication::StartDebugserverProcess() port_cstr after
> socket pipe read
> 
> 
>> Ted's comments are correct and I am guessing we will find the "lldb-server 
>> gdb-server" is not doing the right thing and it isn't returning the 
>> correctly bound port.
>> 
>> When we are doing remote stuff we must use TCP so there should be 
>> lldb-server should be opening a TCP socket, binding, listening and accepting 
>> a connection from the remote LLDB.
>> 
>> Greg
> 
> Greg, thanks for the comments. Are you saying I should check what is
> happening on the TCP socket side? How do I do it other than walking
> through the code?
> 
> 
> root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb-server platform
> --log-file Ramana/remote.log --log-channels "gdb-remote process"
> --server --listen *:1400
> Connection established.
> error: lost connection
> lldb-server exiting...
> ^C
> root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb --version
> lldb version 5.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk
> revision 300578)
>  clang revision 300578
>  llvm revision 300578
> root@arria5:~# cat Ramana/remote.log
> GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0, 
> port=0)
> GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote
> stub exe '/mnt/var/patch_bins/binaries/bin/lldb-server'
> launch info for gdb-remote stub:
> Executable: lldb-server
> Triple: *-*-*
> Arguments:
> argv[0]="/mnt/var/patch_bins/binaries/bin/lldb-server"
> argv[1]="gdbserver"
> argv[2]="tcp://10.10.12.3:0"
> argv[3]="--native-regs"
> argv[4]="--pipe"
> argv[5]="7"
> argv[6]=NULL
> 
> Environment:
> env[0]="XDG_SESSION_ID=c7"
> env[1]="TERM=xterm-256color"
> env[2]="SHELL=/bin/sh"
> env[3]="SSH_CLIENT=172.16.16.51 40072 22"
> env[4]="SSH_TTY=/dev/pts/0"
> env[5]="USER=root"
> env[6]="MAIL=/var/mail/root"
> env[7]="PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin"
> env[8]="PWD=/home/root"
> env[9]="EDITOR=vi"
> env[10]="PS1=\u@\h:\w\$ "
> env[11]="SHLVL=1"
> env[12]="HOME=/home/root"
> env[13]="LOGNAME=root"
> env[14]="SSH_CONNECTION=172.16.16.51 40072 10.10.2.4 22"
> env[15]="XDG_RUNTIME_DIR=/run/user/0"
> env[16]="_=/mnt/var/patch_bins/binaries/bin/lldb-server"
> env[17]=NULL
> 
> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 48039 
> port
> 
> 
> Regards,
> Ramana
> 
> On Thu, Aug 24, 2017 at 10:10 PM, Greg Clayton  wrote:
>> 
>>> On Aug 24, 2017, at 8:33 AM, Ted Woodward  
>>> wrote:
>>> 
>>> The lldb-server launch line looks ok; it should take the port 0 arg and get 
>>> a port from the OS.
>>> lldb is getting the port back from lldb-server in 4.0.1, as seen here:
>>> 
 GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 
 56543 port
>>> 
>>> But for 5.0.0 we see it fail the debugserver launch, and get:
>>> 
 GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 0 
 port
>>> 
>>> That log message comes right after the pipe read, which succeeds because 
>>> error.Success() is true:
>>> 
>>>   // Read port from pipe with 10 second timeout.
>>>   error = socket_pipe.ReadWithTimeout(
>>>   port_cstr, num_bytes, std::chrono::seconds{10}, num_bytes);
>>>   if (error.Success() && (port != nullptr)) {
>>> assert(num_bytes > 0 && port_cstr[num_bytes - 1] == '\0');
>>> uint16_t child_port = StringConvert::ToUInt32(port_cstr, 0);
>>> if (*port == 0 || *port == child_port) {
>>>   *port = child_port;
>>>   if (log)
>>>  

Re: [lldb-dev] remote server crash -> lldb waits forever in accept()

[Chris Bieneman via lldb-dev]

I think in the common case of listening for a remote connection infinite (or 
very very long) timeout with signal interrupt is the preferred approach. There 
are other situations where we use SelectHelper with smaller timeouts, and I 
think ultimately we should replace SelectHelper with MainLoop because they do 
basically the same thing.

-Chris

> On Apr 28, 2017, at 2:53 PM, Jim Ingham  wrote:
> 
> (1) is okay, except pretty much every time so far I've ever said "operation X 
> can't possibly take more than N seconds" somebody finds a case in which that 
> assumption was wrong.  So you end up having to make the timeouts so long they 
> look like stalls anyway...  An explicit cancellation gesture is better if 
> supportable.
> 
> Jim
> 
>> On Apr 28, 2017, at 2:20 PM, Chris Bieneman  wrote:
>> 
>> Ultimately I think the solution here is two changes
>> 
>> (1) We should add a timeout to MainLoop so that it doesn't wait forever 
>> unless we really want to wait forever.
>> (2) MainLoop can exit on sigint for any platform that has ppoll, pselect, or 
>> kevent, so we should probably set that up too.
>> 
>> -Chris
>> 
>> 
>>> On Apr 28, 2017, at 11:06 AM, Jim Ingham via lldb-dev 
>>>  wrote:
>>> 
>>> Seems to me a better UI would be to make ^C interrupt this wait.  That 
>>> seems to me better than putting in some arbitrary timeout.
>>> 
>>> Jim
>>> 
 On Apr 28, 2017, at 10:21 AM, Ted Woodward via lldb-dev 
  wrote:
 
 Hi Chris, Pavel,
 
 I've got a problem launching the hexagon simulator from lldb. It's launched
 the same way that debugserver/lldb-server is launched, with reverse connect
 on a TCP socket. The user can modify the simulator command line (using
 target.run-args), and can easily give a set of options that the simulator
 can't handle. In this case the simulator quits before connecting to lldb,
 and lldb will wait forever for the connection, since TCPSocket::Accept has
 no timeout.
 
 Currently I have a select call before the accept, to make sure there is
 activity on the socket. This doesn't feel right with the new changes using
 MainLoop, so I wanted to see what the list thinks. I believe it will happen
 any time that debugserver/lldb-server quits or crashes before connecting.
 That should be easy to test.
 
 This is what I use, right before the call to accept_loop.Run in
 TCPSocket::Accept:
 
 NativeSocket accept_socket = -1;
 fd_set readset;
 FD_ZERO(&readset);
 for (auto socket : m_listen_sockets) {
   auto fd = socket.first;
   FD_SET(fd, &readset);
   if (fd > accept_socket)
 accept_socket = fd;
 }
 struct timeval timeout = {10, 0};
 int result = ::select(accept_socket + 1, &readset, NULL, NULL,
 &timeout);
 if (result == 0) {
   printf("error: timeout waiting for remote server to connect!\n");
   error.SetErrorString("timeout waiting for remote server to connect");
   return error;
 } else if (result < 0) {
   printf("error: remote server does not exist!\n");
   SetLastError(error);
   return error;
 }
 
 
 Any thoughts this issue?
 
 Ted
 
 --
 Qualcomm Innovation Center, Inc.
 The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
 Linux Foundation Collaborative Project
 
 
 
 ___
 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] remote server crash -> lldb waits forever in accept()

[Chris Bieneman via lldb-dev]

Ultimately I think the solution here is two changes

(1) We should add a timeout to MainLoop so that it doesn't wait forever unless 
we really want to wait forever.
(2) MainLoop can exit on sigint for any platform that has ppoll, pselect, or 
kevent, so we should probably set that up too.

-Chris


> On Apr 28, 2017, at 11:06 AM, Jim Ingham via lldb-dev 
>  wrote:
> 
> Seems to me a better UI would be to make ^C interrupt this wait.  That seems 
> to me better than putting in some arbitrary timeout.
> 
> Jim
> 
>> On Apr 28, 2017, at 10:21 AM, Ted Woodward via lldb-dev 
>>  wrote:
>> 
>> Hi Chris, Pavel,
>> 
>> I've got a problem launching the hexagon simulator from lldb. It's launched
>> the same way that debugserver/lldb-server is launched, with reverse connect
>> on a TCP socket. The user can modify the simulator command line (using
>> target.run-args), and can easily give a set of options that the simulator
>> can't handle. In this case the simulator quits before connecting to lldb,
>> and lldb will wait forever for the connection, since TCPSocket::Accept has
>> no timeout.
>> 
>> Currently I have a select call before the accept, to make sure there is
>> activity on the socket. This doesn't feel right with the new changes using
>> MainLoop, so I wanted to see what the list thinks. I believe it will happen
>> any time that debugserver/lldb-server quits or crashes before connecting.
>> That should be easy to test.
>> 
>> This is what I use, right before the call to accept_loop.Run in
>> TCPSocket::Accept:
>> 
>>   NativeSocket accept_socket = -1;
>>   fd_set readset;
>>   FD_ZERO(&readset);
>>   for (auto socket : m_listen_sockets) {
>> auto fd = socket.first;
>> FD_SET(fd, &readset);
>> if (fd > accept_socket)
>>   accept_socket = fd;
>>   }
>>   struct timeval timeout = {10, 0};
>>   int result = ::select(accept_socket + 1, &readset, NULL, NULL,
>> &timeout);
>>   if (result == 0) {
>> printf("error: timeout waiting for remote server to connect!\n");
>> error.SetErrorString("timeout waiting for remote server to connect");
>> return error;
>>   } else if (result < 0) {
>> printf("error: remote server does not exist!\n");
>> SetLastError(error);
>> return error;
>>   }
>> 
>> 
>> Any thoughts this issue?
>> 
>> Ted
>> 
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project
>> 
>> 
>> 
>> ___
>> 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] [llvm-dev] LLDB security and the use of an IPC library

[Chris Bieneman via lldb-dev]

(+LLDB-Dev) most of the LLDB developers hang out there more than on LLVM-Dev.

> On Apr 26, 2017, at 12:26 PM, Demi Marie Obenour via llvm-dev 
>  wrote:
> 
> LLDB currently uses a client-server architecture.  That appears fine,
> but runs into an annoying security problem: other users on the same
> machine can connect to the TCP socket and take over LLDB and thus the
> user’s system.  This means that LLDB is useless in multiuser
> enviromnents on Linux, such as academic computer labs.
> 
> The immediate problem can be solved by using either HMAC authentication
> of all messages or by using Unix domain sockets.  However, it might be
> simpler to use a 3rd party library for the purpose:
> https://github.com/DemiMarie/SlipRock (Disclaimer: I wrote SlipRock).
> 
> Questions:
> 
> - Would you be interested in using SlipRock?

Probably not. Generally we shy away from using third party libraries.

> 
> - What features would SlipRock need in order to be useful to you?  In
>   particular, do you need an asynchronous API, or is synchronous fine?

The biggest thing that I would see as a barrier for us using SlipRock is that 
it would have to provide a large advantage in order to justify using it. We 
generally don't use middleware libraries that are not readily available on the 
platforms that we support, usually either via a package manager or shipping on 
the OS.

> 
> - If not, would you be willing to accept patches to fix the existing
> bug?

I was actually looking at this code earlier this week. On OS X we do use Unix 
socketpair to construct domain sockets between debugserver and lldb. Presently 
lldb-server (the debugserver implementation used everywhere other than OS X) 
doesn't support accepting a socket pair, but we can and should fix that. I've 
been working recently on making more of LLDB's code properly configured based 
on system capabilities rather than hard coded assumptions. This will make it 
easier for us to do these kinds of things right in the future.

If you're interested in working on getting lldb-server working with socketpair 
we would certainly take the patches, and I'd be happy to provide review or 
guidance as needed.

Thanks,
-Chris

> 
> Sincerely,
> 
> Demi Obenour
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Re: [lldb-dev] Changes in the install of lldb ?

[Chris Bieneman via lldb-dev]

I pushed a fix that should resolve this in r290934.

Sorry for the breakage!
-Chris

> On Dec 25, 2016, at 10:18 AM, Sylvestre Ledru via lldb-dev 
>  wrote:
> 
> Hello
> 
> Recently (couple of weeks), the generation of the apt.llvm.org packages
> is failing because some lldb binaries are sometime no longer generated
> 
> For example, on debian unstable, the following files are no longer
> generated:
> 
> usr/lib/llvm-4.0/bin/lldb-server
> usr/lib/llvm-4.0/bin/lldb-argdumper
> 
> Does is ring a bell to anyone?
> Thanks,
> Sylvestre
> PS: please cc me
> 
> ___
> 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] [RFC] Delete the "testcases" symlink

[Chris Bieneman via lldb-dev]

So, I want to delete the testcases symlink from the LLDB tree, and move the 
tests out of the packages directory into tests/testcases.

A few reasons why I want to do this:
(1) I can't imagine symlinks in SVN is something that works well on platforms 
that don't support symlinks (like Windows)
(2) It trips up scripts and tools that try to operate on the files without 
calling realpath (while I know I could fix those, it is easier to just fix this)
(3) It seems to me that it is completely unnecessary. In lldbsuite's 
__init__.py we already find the test cases by path from the lldb checkout root, 
so having them live in the python packages just seems odd.

Thoughts?

Is there a reason why they need to live in the packages directory that I'm 
unaware of?

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

Re: [lldb-dev] logging in lldb

[Chris Bieneman via lldb-dev]

> On Dec 6, 2016, at 9:32 AM, Pavel Labath  wrote:
> 
> Ah, I totally forgot about the llvm DEBUG macro. I would be open to
> trying merge these two approaches together. However, I think our's is
> a much more heavy-weight system, so it might be too heavy for llvm,
> and I am not sure how much would we be willing to lose in the process:
> - we have two level logging architecture ("process" category in "lldb" 
> channel)

This might not map to LLVM, but it might be worth looking into.

> - logging can be enabled/disabled at runtime

This actually should be doable in LLVM. Since the LLVM DEBUG macro controls the 
-debug=... flag, I can't immediately see a reason why that wouldn't work for 
runtime toggling.

> - logs can be redirected to various destinations

The LLVM logging uses streams, so I don't think this is really different. You 
just change the stream under it.

-Chris

> 
> Maybe it will be possible to design it in a way that the complexity is
> apparent to those who wish to use it. I'll need to think about that...
> 
> pl
> 
> 
> On 6 December 2016 at 17:06, Chris Bieneman  wrote:
>> My only concern reading this is that LLVM already has a similar mechanism 
>> for channel-based logging that is used throughout the backends. Is there a 
>> reason to invent our own? Maybe we can take what is in LLVM, enhance it and 
>> use shared functionality?
>> 
>> There are a few differences between your solution and the LLVM one, but I'm 
>> not sure they are sufficient to justify creating a new solution.
>> 
>> The LLVM debug logging solution is documented in the LLVM Programmers Manual 
>> here:
>> http://llvm.org/docs/ProgrammersManual.html#the-debug-macro-and-debug-option
>> 
>> -Chris
>> 
>>> On Dec 6, 2016, at 8:57 AM, Pavel Labath  wrote:
>>> 
>>> On 6 December 2016 at 16:51, Jim Ingham  wrote:
 Sorry, I'm being dense.  What is Dx?
 
 Jim
 
> On Dec 6, 2016, at 8:23 AM, Pavel Labath  wrote:
> 
> I have created straw-man implementation of such an interface in
> Dx, together with some examples of how it's used, and I'd like to
 
>>> 
>>> https://reviews.llvm.org/D27459 :D
>>> 
>>> Sorry, I forgot to replace this by actual revision when I submitted the 
>>> code.
>>> 
>>> pl
>> 

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

Re: [lldb-dev] logging in lldb

[Chris Bieneman via lldb-dev]

My only concern reading this is that LLVM already has a similar mechanism for 
channel-based logging that is used throughout the backends. Is there a reason 
to invent our own? Maybe we can take what is in LLVM, enhance it and use shared 
functionality?

There are a few differences between your solution and the LLVM one, but I'm not 
sure they are sufficient to justify creating a new solution.

The LLVM debug logging solution is documented in the LLVM Programmers Manual 
here:
http://llvm.org/docs/ProgrammersManual.html#the-debug-macro-and-debug-option

-Chris

> On Dec 6, 2016, at 8:57 AM, Pavel Labath  wrote:
> 
> On 6 December 2016 at 16:51, Jim Ingham  wrote:
>> Sorry, I'm being dense.  What is Dx?
>> 
>> Jim
>> 
>>> On Dec 6, 2016, at 8:23 AM, Pavel Labath  wrote:
>>> 
>>> I have created straw-man implementation of such an interface in
>>> Dx, together with some examples of how it's used, and I'd like to
>> 
> 
> https://reviews.llvm.org/D27459 :D
> 
> Sorry, I forgot to replace this by actual revision when I submitted the code.
> 
> pl

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

Re: [lldb-dev] [llvm-dev] [RFC] Runtime checks for ABI breaking build of LLVM

[Chris Bieneman via lldb-dev]

Mehdi,

I think your second approach is the better option. Going with the first option 
means we would need to remove references to llvm-config.h in ADT, which I don't 
think is a simple task.

-Chris

> On Nov 18, 2016, at 4:23 PM, Mehdi Amini via llvm-dev 
>  wrote:
> 
> 
>> On Nov 18, 2016, at 3:45 PM, Mehdi Amini > > wrote:
>> 
>> Hi,
>> 
>> I had to revert it, because it breaks building LLDB on MacOS.
>> 
>> It turns out it would break any client that is including llvm-config.h but 
>> not linking to libLLVMSupport.
>> So either:
>> 
>> - we shouldn’t allow to include llvm-config.h without linking to LLVM, in 
>> which case I need to look a bit closer as of why lldb includes this header 
>> in a context where they don’t link LLVM.
>> - we should allow to include llvm-config.h without linking to LLVM (at least 
>> libSupport). In which case we need a new solution for this feature: it can 
>> be to use another header dedicated to this flag, that would be included only 
>> from headers that contain the ABI break.
> 
> The second approach is implemented here:  https://reviews.llvm.org/D26876 
> 
> 
> I extracted the LLVM_ENABLE_ABI_BREAKING_CHECKS to its own header to have a 
> fine granularity on which client needs to include the check.
> 
> — 
> Mehdi
> 
> 
> 
> 
>> 
>> 
>>> On Nov 16, 2016, at 12:12 PM, Mehdi Amini via llvm-dev 
>>> mailto:llvm-...@lists.llvm.org>> wrote:
>>> 
 
 On Nov 16, 2016, at 12:05 PM, Jonathan Roelofs >>> > wrote:
 
 
 
 On 11/16/16 11:48 AM, Mehdi Amini via llvm-dev wrote:
> Hi all,
> 
> An issue that come up from time to time and has cost hours for debug for
> many of us and users of LLVM is that an assert build isn’t ABI
> compatible with a release build.
> 
> The CMake flags that controls this behavior is LLVM_ABI_BREAKING_CHECKS (
> 
> *LLVM_ABI_BREAKING_CHECKS*:STRING
>Used to decide if LLVM should be built with ABI breaking checks or
>not. Allowed values
>are WITH_ASSERTS (default), FORCE_ON and FORCE_OFF.  WITH_ASSERTS turns
>on ABI breaking checks in an assertion enabled
>build.  FORCE_ON (FORCE_OFF) turns them on (off) irrespective of
>whether normal (NDEBUG-based) assertions are enabled or not. A
>version of LLVM built with ABI breaking checks is not ABI compatible
>with a version built without it.
> 
> 
> I propose to add a runtime check to detect when we have incorrectly
> setup build.
> 
> The idea is that every translation unit that includes such header will
> get a weak definition of a symbol with an initializer calling the
> runtime check. The symbol name would be different if the ABI break is
> enabled or not.
 
 Can it be made into a link-time check instead? I'm imagining something 
 like:
>>> 
>>> I’d love to, but didn’t find a universal solution unfortunately :(
>>> 
  #if LLVM_ENABLE_ABI_BREAKING_CHECKS
  extern int EnableABIBreakingChecks;
  __attribute__((weak)) int *VerifyEnableABIBreakingChecks = 
 &EnableABIBreakingChecks;
  #else
  extern int DisableABIBreakingChecks;
  __attribute__((weak)) int *VerifyDisableABIBreakingChecks = 
 &VDisableABIBreakingChecks;
  #endif
 
 in llvm-config.h.cmake, and:
 
  #if LLVM_ENABLE_ABI_BREAKING_CHECKS
  int EnableABIBreakingChecks;
  #else
  int DisableABIBreakingChecks;
  #endif
 
 in Error.cpp.
 
 Then it'll only link if Error.cpp's TU's setting of 
 LLVM_ENABLE_ABI_BREAKING_CHECKS matches that of the TU that includes 
 llvm-config.h
>>> 
>>> It seems that this work, I thought I tried exactly this but got lost on the 
>>> whiteboard at some point!
>>> 
>>> Maybe because one drawback that I tried to avoid is that the export-list of 
>>> a LLVM dylib would depend on the value of LLVM_ENABLE_ABI_BREAKING_CHECKS 
>>> with this.
>>> 
>>> Thanks,
>>> 
>>> — 
>>> Mehdi
>>> 
>>> 
>>> 
>>> 
>>> 
 
 
> 
> The runtime check maintains two boolean to track if it there is in the
> image at least a translation unit for each value of this flag. If both
> flags are set the process is aborted.
> 
> The cost is *one* static initializer per DSO (or per image I believe).
> 
> A straw-man patch (likely not windows compatible because of weak) is:
> 
> diff --git a/llvm/include/llvm/Config/llvm-config.h.cmake
> b/llvm/include/llvm/Config/llvm-config.h.cmake
> index 4121e865ea00..4274c942d3b6 100644
> --- a/llvm/include/llvm/Config/llvm-config.h.cmake
> +++ b/llvm/include/llvm/Config/llvm-config.h.cmake
> @@ -80,4 +80,18 @@
> /* LLVM version string */
> #define LLVM_VERSION_STRING "${PACKAGE_VERSION}"
> 
> +
> +#ifdef __cplusplus
> +namespace llvm {
> +bool setABIBreakingChecks(bool Enabl

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

[Chris Bieneman via lldb-dev]

> On Oct 20, 2016, at 1:00 PM, Tamas Berghammer via lldb-dev 
>  wrote:
> 
> Building LLDB with cmake is already supported on all operating systems 
> (including Darwin) for a while so that shouldn't be a blocker.

While this is technically true, the LLDB test suite makes a lot of assumptions 
that if you’re on Darwin you built with Xcode, which results in lots of tests 
not executing at all.

-Chris

> 
> On Thu, Oct 20, 2016 at 8:09 PM Tim Hammerquist via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> IIRC, the only reason the LLDB python test suite uses the in-tree compiler 
> (Scenario 1) was so to test sanitizers before they were available in the 
> system compiler. If that's the case, then using Xcode 8 on the builder will 
> allow both the LLDB build and tests to use the system compiler.
> 
> As I understand it, there are a few ways to go about building lldb using the 
> ToT (or at least, last green) compiler. This approach will be of limited use 
> until building lldb with cmake is supported, however. I'm following up on 
> this timeline.
> 
> -Tim
> 
> 
> On Thu, Oct 20, 2016 at 11:50 AM, Ted Woodward  > wrote:
> I think a hardcoded value of 1 for maximum_operations_per_instruction will 
> work like it does today – 1 linetable entry per Hexagon packet, which may 
> have 1-4 instructions in it. Hexagon executes 1 packet at a time, so anywhere 
> from 1-4 instructions at once.
> 
>  
> 
> At O0, the compiler doesn’t packetize instructions, so 1 instruction is run 
> at a time. At 01 it will, but it doesn’t do many other optimizations. We 
> should still have 1 line per packet. O2 and O3 can move instructions around, 
> so will have up to 4 source lines in 1 packet. I think we’ll need to 
> experiment internally with what that means for the debugger, once we get this 
> change.
> 
>  
> 
> --
> 
> Qualcomm Innovation Center, Inc.
> 
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
> 
>  
> 
> From: Eric Christopher [mailto:echri...@gmail.com 
> ] 
> Sent: Wednesday, October 19, 2016 6:09 PM
> To: Tim Hammerquist mailto:pen...@gmail.com>>
> Cc: Greg Clayton mailto:gclay...@apple.com>>; Ted 
> Woodward mailto:ted.woodw...@codeaurora.org>>; 
> LLDB mailto:lldb-dev@lists.llvm.org>>
> Subject: Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4
> 
>  
> 
>  
> 
> On Wed, Oct 19, 2016 at 3:34 PM Tim Hammerquist  > wrote:
> 
> I was mistaken.
> 
>  
> 
> The system toolchain builds stage1 llvm, clang & co.
> 
> The system toolchain builds lldb containing the llvm/clang/etc bits.
> 
> The system toolchain builds gtest test programs. 
> 
> The stage1 compiler builds the python test inferiors.
> 
>  
> 
>  
> 
> OK, then it sounds like at least some of the test programs are built with the 
> new compiler? IIRC the python test inferiors here are the programs that are 
> the meat of the testsuite for lldb yes?
> 
>  
> 
> If so, then on check-in we should possibly see some difference on some bot if 
> they all use the same general configuration.  I don't have a current checkout 
> so I don't know if the default -g is used or if it's set to a different dwarf 
> level. Currently it looks like clang will use dwarf4 by default with -g:
> 
>  
> 
> echristo@dzur ~/tmp> ~/builds/build-llvm/bin/clang -c foo.c -o - -target 
> x86_64-apple-macosx10.11 -g | llvm-dwarfdump - | grep version | grep -v clang
> 
> 0x: Compile Unit: length = 0x0037 version = 0x0004 abbr_offset = 
> 0x addr_size = 0x08 (next unit at 0x003b)
> 
>  version: 2
> 
>  
> 
> where the first line is the debug_info header and the second is the version 
> in the line table.
> 
>  
> 
> Ted/Greg: Relatedly, what brought this up was the vliw aspect with 
> maximum_operations_per_instruction - it's being hard coded to 1 here and I'm 
> not sure how we want to deal with that on hexagon? Currently it'll be hard 
> set to 1 so line stepping will work as I imagine it currently does. That 
> said, if we wanted to take advantage of it then that's different. Primarily I 
> wasn't sure if Ted and folk had a debugger that did take advantage of it if 
> it was there.
> 
>  
> 
> Thanks!
> 
>  
> 
> -eric
> 
>  
> 
>  
> 
> On Wed, Oct 19, 2016 at 3:28 PM, Eric Christopher  > wrote:
> 
>  
> 
> On Wed, Oct 19, 2016 at 3:26 PM Tim Hammerquist  > wrote:
> 
> The LLDB job in llvm.org  will build a stage1 RA with 
> llvm+clang+libcxx+compiler-rt using the system compiler, and use the new 
> compiler to build lldb.
> 
>  
> 
> By default, this is kicked off automatically when a clang stage1 RA is 
> successful, but can be manually triggered to build HEAD, or any revision 
> desired.
> 
>  
> 
> The python test suite (invoked with the xcodebuild target 
> lldb-python-test-suite) uses the newly built 

Re: [lldb-dev] Build failure with llvm/IR/Attributes.gen?

[Chris Bieneman via lldb-dev]

This is a different missing dependency. I've committed r283081 to fix this one 
and another one that I found. Hopefully that should get things working.

-Chris

> On Oct 2, 2016, at 5:39 AM, Kamil Rytarowski  wrote:
> 
> It's still broken for NetBSD
> 
> http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd7/builds/6775
> 
>> On 30.09.2016 01:04, Chris Bieneman via lldb-dev wrote:
>> Hal, thanks for the heads up. I just committed a patch that should resolve 
>> this in r282803.
>> 
>> Thanks!
>> -Chris
>> 
>>> On Sep 29, 2016, at 1:49 PM, Hal Finkel  wrote:
>>> 
>>> - Original Message -
>>>> From: "Hal Finkel via lldb-dev" 
>>>> To: lldb-dev@lists.llvm.org
>>>> Sent: Thursday, September 29, 2016 2:51:03 PM
>>>> Subject: [lldb-dev] Build failure with llvm/IR/Attributes.gen?
>>>> 
>>>> Hi everyone,
>>>> 
>>>> Starting a few days ago (between Sept 22nd and 23rd) my nightly
>>>> builds including lldb starting failing:
>>>> 
>>>> In file included from /path/to/llvm/include/llvm/IR/Argument.h:19:0,
>>>>from /path/to/llvm/include/llvm/IR/Function.h:22,
>>>>from /path/to/llvm/include/llvm/IR/Module.h:21,
>>>>from
>>>>
>>>> /path/to/llvm/tools/lldb/include/lldb/Expression/IRExecutionUnit.h:22,
>>>>from
>>>>
>>>> /path/to/llvm/tools/lldb/source/Expression/ExpressionVariable.cpp:12:
>>>> /path/to/llvm/include/llvm/IR/Attributes.h:71:38: fatal error:
>>>> llvm/IR/Attributes.gen: No such file or directory
>>>>#include "llvm/IR/Attributes.gen"
>>>> ^
>>>> compilation terminated.
>>>> 
>>>> This might be simply the result of some unexpressed dependency in the
>>>> cmake files (my build uses make -j72, so it tends to find these
>>>> kinds of issues when they come up). Any ideas?
>>> 
>>> [+Chris B.]
>>> 
>>> Doing this seems to help:
>>> 
>>> diff --git a/CMakeLists.txt b/CMakeLists.txt
>>> index 85d4b51..9615a3c 100644
>>> --- a/CMakeLists.txt
>>> +++ b/CMakeLists.txt
>>> @@ -765,9 +765,9 @@ add_subdirectory(utils/TableGen)
>>> # an entire module might include header, which depends on intrinsics_gen. 
>>> This
>>> # should be right after LLVMSupport and LLVMTableGen otherwise we introduce 
>>> a
>>> # circular dependence.
>>> -if (LLVM_ENABLE_MODULES)
>>> +#if (LLVM_ENABLE_MODULES)
>>>  list(APPEND LLVM_COMMON_DEPENDS intrinsics_gen)
>>> -endif(LLVM_ENABLE_MODULES)
>>> +#endif(LLVM_ENABLE_MODULES)
>>> 
>>> add_subdirectory(include/llvm)
>>> 
>>> but that does not seem like a real solution.
>>> 
>>> -Hal
>>> 
>>>> 
>>>> Thanks again,
>>>> Hal
>>>> 
>>>> --
>>>> Hal Finkel
>>>> Lead, Compiler Technology and Programming Languages
>>>> Leadership Computing Facility
>>>> Argonne National Laboratory
>>>> ___
>>>> lldb-dev mailing list
>>>> lldb-dev@lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>> 
>>> 
>>> -- 
>>> Hal Finkel
>>> Lead, Compiler Technology and Programming Languages
>>> Leadership Computing Facility
>>> Argonne National Laboratory
>> 
>> ___
>> 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] Build failure with llvm/IR/Attributes.gen?

[Chris Bieneman via lldb-dev]

Hal, thanks for the heads up. I just committed a patch that should resolve this 
in r282803.

Thanks!
-Chris

> On Sep 29, 2016, at 1:49 PM, Hal Finkel  wrote:
> 
> - Original Message -
>> From: "Hal Finkel via lldb-dev" 
>> To: lldb-dev@lists.llvm.org
>> Sent: Thursday, September 29, 2016 2:51:03 PM
>> Subject: [lldb-dev] Build failure with llvm/IR/Attributes.gen?
>> 
>> Hi everyone,
>> 
>> Starting a few days ago (between Sept 22nd and 23rd) my nightly
>> builds including lldb starting failing:
>> 
>> In file included from /path/to/llvm/include/llvm/IR/Argument.h:19:0,
>> from /path/to/llvm/include/llvm/IR/Function.h:22,
>> from /path/to/llvm/include/llvm/IR/Module.h:21,
>> from
>> 
>> /path/to/llvm/tools/lldb/include/lldb/Expression/IRExecutionUnit.h:22,
>> from
>> 
>> /path/to/llvm/tools/lldb/source/Expression/ExpressionVariable.cpp:12:
>> /path/to/llvm/include/llvm/IR/Attributes.h:71:38: fatal error:
>> llvm/IR/Attributes.gen: No such file or directory
>> #include "llvm/IR/Attributes.gen"
>>  ^
>> compilation terminated.
>> 
>> This might be simply the result of some unexpressed dependency in the
>> cmake files (my build uses make -j72, so it tends to find these
>> kinds of issues when they come up). Any ideas?
> 
> [+Chris B.]
> 
> Doing this seems to help:
> 
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 85d4b51..9615a3c 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -765,9 +765,9 @@ add_subdirectory(utils/TableGen)
> # an entire module might include header, which depends on intrinsics_gen. This
> # should be right after LLVMSupport and LLVMTableGen otherwise we introduce a
> # circular dependence.
> -if (LLVM_ENABLE_MODULES)
> +#if (LLVM_ENABLE_MODULES)
>   list(APPEND LLVM_COMMON_DEPENDS intrinsics_gen)
> -endif(LLVM_ENABLE_MODULES)
> +#endif(LLVM_ENABLE_MODULES)
> 
> add_subdirectory(include/llvm)
> 
> but that does not seem like a real solution.
> 
> -Hal
> 
>> 
>> Thanks again,
>> Hal
>> 
>> --
>> Hal Finkel
>> Lead, Compiler Technology and Programming Languages
>> Leadership Computing Facility
>> Argonne National Laboratory
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 
> 
> -- 
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory

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

Re: [lldb-dev] [OS X]: building lldb with cmake

[Chris Bieneman via lldb-dev]

> On Sep 10, 2016, at 12:11 PM, René J.V. Bertin via lldb-dev 
>  wrote:
> 
> On Saturday September 10 2016 17:26:26 Michał Górny wrote:
> 
> Re: MIUtilParse: I'm building the 3.9.0 release so no worries that the class 
> has been added back supposing it was removed *after* the release.
> 
>>> Agree that a standalone build would be great to have working, it just
>>> requires someone willing and able to come along and fix it :)
>> 
>> I have it on my TODO but honestly speaking, LLDB is a bit of a mess
>> right now and I'm not even sure where to start. So far I'm focusing
>> on the other LLVM components but I should be able to get to LLDB soon.
>> Though I can't promise much since my time is quite limited.
> 
> There really isn't much to be done to get it to work, esp. if the 
> abovementioned class is already removed:
> 
> - fix finding CheckAtomic.cmake (or just install it with LLVM)

CheckAtomic is installed with LLVM on trunk, and will be this way in future 
releases.

> - fix the install location as recorded in liblldb and make sure that location 
> gets added to the rpath in lldb, lldb-mi and other dependents.
> 
> There's also an issue finding the proper Python library, at least when 
> building MacPorts. It finds the correct framework binary when doing a 
> complete build using the toplevel CMake file, but apparently goes for the 
> latest version if you use the standalone build.
> 
> R.
> ___
> 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] [3.9 Release] Please write release notes!

[Chris Bieneman via lldb-dev]

> On Aug 2, 2016, at 4:46 PM, Hans Wennborg  wrote:
> 
> Dear everyone,
> 
> It's time for the release notes nagging email.
> 
> We have release notes for LLVM, Clang, clang-tools-extra, lld, and
> Polly. (If there are more, please let me know.)
> 
> Most of these are pretty empty files; see e.g. the LLVM one at [1].
> The internet does read these notes when we release, so please help
> make them informative!
> 
> If you made any interesting changes during the past six months, or
> know someone who did, please write something for the release notes.
> You can commit them directly to the branch, or send a patch to me and
> I'll happily commit them for you.
> 
> If you feel responsible for a particular target, e.g. X86, ARM, MIPS,
> etc., please help give those release notes some love.
> 
> 
> Here are some examples we might want to mention (thanks LLVM Weekly!).
> If you're cc'd on this email, you're mentioned below.
> 
> - Dmitry, Renato: the Clang notes mention abi_tag. Do we want to
> expand the text here a little? Link to the PR?
> 
> - Teresa, Mehdi: there's a "Introduction of ThinLTO [..] ping
> Mehdi/Teresa before the release if not done" note, so here's the ping
> :-) We should link to the blog post as well.
> 
> - Chris Bieneman, there's a "note about autoconf build having been
> removed". Do you want to expand this? :-)

Updated in r277617. Thanks!
-Chris

> 
> - Danny, George: do you want to add something about MemorySSA?
> 
> - Nico, do you want to mention clang-cl's precompiled header support?
> 
> - James, do you want to mention the removal of the CppBackend?
> 
> - Chris Dewhurst, do you want to mention soft-float SPARC support (and
> potentially other SPARC improvements)?
> 
> - Benjamin, should we mention include-fixer somewhere?
> 
> Many thanks,
> Hans
> 
> 
> [1] 
> http://llvm.org/viewvc/llvm-project/llvm/branches/release_39/docs/ReleaseNotes.rst?view=markup

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

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[Chris Bieneman via lldb-dev]

My personal 2 cents is that I’d love to see us move to github and a git-native 
workflow. I’m already on a mostly git workflow and the only thing that tears me 
out of it is git-svn, which corrupts itself way too often.

As a late-comer on the thread I do have a few thoughts I want to share based on 
the discussion.

(1) We really don’t know how many users are using git vs svn. What if we 
encouraged users on git to setup a commit-msg hook that appended text to the 
end of their commit messages to identify the commits as being from git?

Something like this -> http://reviews.llvm.org/P4788

Then we could figure out easily a rough approximation of how many of our 
developers are on git vs svn. Having that information would make a lot of these 
discussions more clear, and it would give us some level of empirical data.

(2) I strongly think merging repositories is a bad idea. In particular we 
support building clang without having an LLVM checkout by building against an 
installed LLVM. Merging the repositories would break this, and that may be an 
important feature. Similarly compiler-rt is used with GCC, so we need to 
support it not being in the LLVM repo. All of this gets messy.

(3) Submodules can be messy. I’d prefer if we had a solution where they were 
optional or something like the github llvm-project-submodule setup where the 
submodules are all part of a separate repository. We could even make it so that 
repository is updated by a bot only after a successful compile. That would be 
kinda cool.

-Chris


> On Jun 2, 2016, at 9:28 AM, Scott Warren via cfe-dev  
> wrote:
> 
> My two cents worth: our group tries very hard to avoid Git because we find it 
> immature, hard to use, and unreliable. I know others feel differently but our 
> vote is to stay with SVN. If distributed repositories are a priority we’d be 
> much happier with Mercurial.
> 
> skw
> 
> 
>> On Jun 2, 2016, at 11:21 AM, Tanya Lattner via cfe-dev 
>> mailto:cfe-...@lists.llvm.org>> wrote:
>> 
>> I personally find this email thread very hard to follow and read (this isn’t 
>> anyones fault.. its just a lot of replies). I am sure others do as well. I 
>> think it would be good to have a form/survey of some sort that can get 
>> feedback from users such as: who they are, how they use 
>> LLVM/contributions/etc,  if they are pro-github move, how it impacts them, 
>> etc. People could then submit their feedback in an organized way and we 
>> could get a better idea of how the community feels on the topic. 
>> 
>> I am happy to try to set something like this up.
>> 
>> -Tanya
>> 
>>> On Jun 2, 2016, at 8:48 AM, Renato Golin via llvm-dev 
>>>  wrote:
>>> 
>>> A little summary...
>>> 
>>> After a lot of discussion, I think we converged to a few issues that
>>> we need to solved before we finally decide to move.
>>> 
>>> Firstly, the responses were overwhelmingly positive (I counted 20 of
>>> the ~25 people strongly supporting and another 2~3 weakly supporting).
>>> This is a good indication that the move could be very beneficial to
>>> the community as a whole, including downstream infrastructure, not
>>> just the reduction in upstream infrastructure admin costs.
>>> 
>>> But that doesn't mean we have cleared up all the issues...
>>> 
>>> 
>>>  The benefits I gathered from the thread:
>>> 
>>> * Infrastructure admin (not just server costs) is too expensive.
>>> We're not sysadmins and maintaining all the tools is a full time job.
>>> Volunteering works for odd problems, not for production services.
>>> Furthermore, most of the infrastructure we need is covered by
>>> GitHub/Lab/BB for free, on a scale that we would not have, even with a
>>> full time sysadmin. Gratis.
>>> 
>>> * Having one official repository instead of two is beneficial to most
>>> developers. A lot of people (most people replying on this thread), use
>>> Git in addition to SVN. Git also seems to be used more on validation
>>> infrastructure than SVN (no example was put forward on this thread, at
>>> least), due to the simplicity of controlling the repository and the
>>> tools available. Reports of how teams decided to script Git to have
>>> linear behaviour instead of falling back to SVN are enlightening.
>>> 
>>> * Git developer tooling is a growing trend, while SVN tooling is
>>> dying. This is not just about GUIs, but repository management (GitHub,
>>> GitLab, BitBucket, etc versus SourceForge), bisects, branches,
>>> remotes, hooks, workdir, submodules and all the new development seem
>>> to be done on Git nowadays, not SVN. Windows may be an odd one related
>>> to GUIs, but Visual Studio has Git integration and I hear it's similar
>>> to the other MSVC VCSs. GitHub's desktop interface seems pretty cool,
>>> too.
>>> 
>>> * Web repositories make it *a lot* easier to create add-hoc pull
>>> requests by non-developers, which could boost the number of
>>> contributions and future contributors, as well as external projects
>>> using LLVM components.
>>> 
>>> * GitHub's SVN

Re: [lldb-dev] TODAY! Updating to CMake 3.4.3

[Chris Bieneman via lldb-dev]

One more thing I want to note on this thread.

For anyone looking at the patches. I’ve intentionally tried to make them 
minimal. After the patches have landed and stayed on trunk without issue for a 
while I’ll start doing cleanup around all the CMake version checks.

I’d like to not open the flood gates on those kinds of cascading changes in 
case these patches need to be reverted for some reason.

Thanks,
-Chris

> On May 31, 2016, at 11:22 AM, Chris Bieneman via lldb-dev 
>  wrote:
> 
> Just an FYI. Later today I’ll be updating the CMake minimum version to 3.4.3. 
> In advance of the transition I’ve posted a bunch of patches:
> 
> LLVM: http://reviews.llvm.org/D20822
> Clang: http://reviews.llvm.org/D20823
> Compiler-RT: http://reviews.llvm.org/D20824
> LLDB: http://reviews.llvm.org/D20826
> libcxx: http://reviews.llvm.org/D20828
> libcxxabi: http://reviews.llvm.org/D20829
> 
> I will commit the patches early this afternoon. 
> 
> I received a lot of responses from bot owners on my last thread 
> (http://lists.llvm.org/pipermail/llvm-dev/2016-May/100058.html), so I think 
> we’ll be in good shape, but I will be watching closely.
> 
> If you maintain a bot that *hasn’t* yet been updated please contact me right 
> away so that we can coordinate.
> 
> Thanks,
> -Chris
> ___
> 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] TODAY! Updating to CMake 3.4.3

[Chris Bieneman via lldb-dev]

Just an FYI. Later today I’ll be updating the CMake minimum version to 3.4.3. 
In advance of the transition I’ve posted a bunch of patches:

LLVM: http://reviews.llvm.org/D20822
Clang: http://reviews.llvm.org/D20823
Compiler-RT: http://reviews.llvm.org/D20824
LLDB: http://reviews.llvm.org/D20826
libcxx: http://reviews.llvm.org/D20828
libcxxabi: http://reviews.llvm.org/D20829

I will commit the patches early this afternoon. 

I received a lot of responses from bot owners on my last thread 
(http://lists.llvm.org/pipermail/llvm-dev/2016-May/100058.html), so I think 
we’ll be in good shape, but I will be watching closely.

If you maintain a bot that *hasn’t* yet been updated please contact me right 
away so that we can coordinate.

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

[lldb-dev] [Attn: Bot Owners!] Raising CMake minimum version to 3.4.3

[Chris Bieneman via lldb-dev]

Meant to send this yesterday, but I want to remind everyone that we’re going to 
be raising the CMake minimum version to 3.4.3 next week.

If you maintain bots please ensure that your bots are updated by end of day 
5/29 so that we can move on 5/30 (next Monday).

I have already heard from most bot owners either saying they had made the 
change, or scheduled to make it.

If you have any questions or concerns please let me know.

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