[lldb-dev] [5.0.0 Release] Release Candidate 3 tagged

2017-08-25 Thread Hans Wennborg via lldb-dev 
Dear testers,

5.0.0-rc3 was just tagged.

This is a release candidate in the real sense: if nothing bad comes up
in testing, this is what the release is going to look like.

Please build, test and upload binaries to the sftp (use the
/data/testers-uploads/ directory) and let me know what issues remain.

I know we're a little bit behind schedule, but hopefully we can get to
'final' soon.

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

Re: [lldb-dev] hang bug in lldb-mi -var-update

2017-08-25 Thread Greg Clayton via lldb-dev 
lldb-mi should never be checking the children. This is never a good idea due to 
performance. What happens when you have an array with a million entries? Long 
delay. Aggregate types should never say they changed. Only SBValue objects that 
have values should claim to change.

Greg


> On Aug 25, 2017, at 10:42 AM, Ted Woodward via lldb-dev 
>  wrote:
> 
> I found a hang in lldb-mi's -var-update. It checks to see if a var changed,
> then it checks each of the children recursively. If a child is a pointer
> back to a parent, as in this case:
> 
> struct complex_type
> {
>int i;
>struct { long l; } inner;
>struct complex_type *complex_ptr;
> };
> 
> void
> var_update_test(void)
> {
>struct complex_type complx_array[2];
> 
>complx_array[0].i = 4;
>complx_array[0].inner.l = 4;
>complx_array[0].complex_ptr = _array[1];
>complx_array[1].i = 5;
>complx_array[1].inner.l = 5;
>complx_array[1].complex_ptr = _array[0];
> 
> 
> 
> the code in CMICmdCmdVarUpdate::ExamineSBValueForChange will get into an
> infinite loop.
> 
>  const MIuint nChildren = vrwValue.GetNumChildren();
>  for (MIuint i = 0; i < nChildren; ++i) {
>lldb::SBValue member = vrwValue.GetChildAtIndex(i);
>if (!member.IsValid())
>  continue;
> 
>if (member.GetValueDidChange()) {
>  vrwbChanged = true;
>  return MIstatus::success;
>} else if (ExamineSBValueForChange(member, vrwbChanged) && vrwbChanged)
>  // Handle composite types (i.e. struct or arrays)
>  return MIstatus::success;
>  }
> 
> I've got a patch that disables checking a pointer's children. I'll put it up
> on phabricator today.
> 
> 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

Re: [lldb-dev] [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged

2017-08-25 Thread Simon Dardis via lldb-dev 


> -Original Message-
> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf
> Of Hans Wennborg
> Sent: 24 August 2017 22:50
> To: Simon Dardis
> Cc: Release-testers; llvm-dev; cfe-dev; openmp-dev (openmp-
> d...@lists.llvm.org); LLDB Dev
> Subject: Re: [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged
> 
> On Tue, Aug 1, 2017 at 3:01 AM, Simon Dardis 
> wrote:
> > Hi all,
> >
> > I have new regressions for mips(el)-linux-gnu, some of which I have
> patches for:
> >
> > I have patch for (believe this to be a libc bug):
> > LLVM-Unit ::
> DebugInfo/DWARF/./DebugInfoDWARFTests/DWARFDebugInfo.TestDwarfV
> erifyInvalidCURef
> > LLVM-Unit ::
> DebugInfo/DWARF/./DebugInfoDWARFTests/DWARFDebugInfo.TestDwarfV
> erifyInvalidLineFileIndex
> > LLVM-Unit ::
> DebugInfo/DWARF/./DebugInfoDWARFTests/DWARFDebugInfo.TestDwarfV
> erifyInvalidLineSequence
> > LLVM-Unit ::
> >
> DebugInfo/DWARF/./DebugInfoDWARFTests/DWARFDebugInfo.TestDwarfV
> erifyIn
> > validStmtList This appears to be a known regression (PR32910):
> > Builtins-mips64-linux :: divtc3_test.c New, investigating:
> > Clang :: Index/IBOutletCollection.m
> > Clang :: Index/TestClassDecl.m
> > Clang :: Index/TestClassForwardDecl.m
> > Clang :: Index/allow-editor-placeholders.cpp
> > Clang :: Index/annotate-attribute.cpp
> > Clang :: Index/annotate-comments-availability-attrs.cpp
> > Clang :: Index/annotate-comments-objc.m
> > Clang :: Index/annotate-comments-property-accessor.m
> > Clang :: Index/annotate-comments-typedef.m
> > Clang :: Index/annotate-comments-unterminated.c
> > Clang :: Index/annotate-comments.cpp
> > Clang :: Index/annotate-context-sensitive.cpp
> > Clang :: Index/annotate-deep-statements.cpp
> > Clang :: Index/annotate-literals.m
> > Clang :: Index/annotate-macro-args.m
> > Clang :: Index/annotate-module.m
> > Clang :: Index/annotate-nested-name-specifier.cpp
> > Clang :: Index/annotate-parameterized-classes.m
> > Clang :: Index/annotate-subscripting.m
> > Clang :: Index/annotate-tokens-cxx0x.cpp
> > Clang :: Index/annotate-tokens-include.c
> > Clang :: Index/annotate-tokens-pp.c
> > Clang :: Index/annotate-tokens-preamble.c
> > Clang :: Index/annotate-tokens-with-default-args.cpp
> > Clang :: Index/annotate-tokens.c
> > Clang :: Index/annotate-tokens.cpp
> > Clang :: Index/annotate-tokens.m
> > Clang :: Index/annotate-toplevel-in-objccontainer.m
> > Clang :: Index/arc-annotate.m
> > Clang :: Index/asm-attribute.c
> > Clang :: Index/attributes-cuda.cu
> > Clang :: Index/attributes.c
> > Clang :: Index/availability.c
> > Clang :: Index/availability.cpp
> > Clang :: Index/blocks.c
> > Clang :: Index/boxed-exprs.m
> > Clang :: Index/c-index-api-loadTU-test.m
> > Clang :: Index/c-index-getCursor-pp.c
> > Clang :: Index/c-index-getCursor-test.m
> > Clang :: Index/c-index-pch.c
> > Clang :: Index/c-index-redecls.c
> > Clang :: Index/cindex-from-source.m
> > Clang :: Index/cindex-on-invalid.m
> > Clang :: Index/comment-c-decls.c
> > Clang :: Index/comment-cplus-decls.cpp
> > Clang :: Index/comment-cplus-template-decls.cpp
> > Clang :: Index/comment-cplus11-specific.cpp
> > Clang :: Index/comment-custom-block-command.cpp
> > Clang :: Index/comment-lots-of-unknown-commands.c
> > Clang :: Index/comment-misc-tags.m
> > Clang :: Index/comment-objc-decls.m
> > Clang :: Index/comment-objc-parameterized-classes.m
> > Clang :: Index/comment-to-html-xml-conversion.cpp
> > Clang :: Index/comment-unqualified-objc-pointer.m
> > Clang :: Index/comment-with-preamble.c
> > Clang :: Index/complete-module-undef.m
> > Clang :: Index/crash-recovery-modules.m
> > Clang :: Index/ctor-init-source-loc.cpp
> > Clang :: Index/cursor-ref-names.cpp
> > Clang :: Index/cxx11-lambdas.cpp
> > Clang :: Index/evaluate-cursor.cpp
> > Clang :: Index/file-includes.c
> > Clang :: Index/file-macro-refs.c
> > Clang :: Index/file-refs-subscripting.m
> > Clang :: Index/file-refs.c
> > Clang :: Index/file-refs.cpp
> > Clang :: Index/file-refs.m
> > Clang :: Index/fix-its.c
> > Clang :: Index/fix-its.m
> > Clang :: Index/format-comment-cdecls.c
> > Clang :: Index/get-cursor-includes.c
> > Clang :: Index/get-cursor.c
> > Clang :: Index/get-cursor.cpp
> > Clang :: Index/get-cursor.m
> > Clang :: Index/getcursor-pp-pch.c
> > Clang :: Index/getcursor-preamble.m
> > Clang :: Index/headerfile-comment-to-html.m
> > Clang :: Index/in-class-init.cpp
> > Clang :: Index/index-attrs.c
> > Clang :: Index/index-attrs.cpp
> > Clang :: Index/index-attrs.m
> > Clang :: Index/index-decls.m
> > Clang :: Index/index-file.cpp
> > Clang :: Index/index-file.cu
> > Clang :: Index/index-invalid-code.m
> >

Re: [lldb-dev] [llvm-dev] [5.0.0 Release] Only 3 release blockers left, please help fix!

2017-08-25 Thread Robinson, Paul via lldb-dev 


> -Original Message-
> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of Hans
> Wennborg via llvm-dev
> Sent: Thursday, August 24, 2017 6:06 PM
> To: llvm-dev; cfe-dev; LLDB Dev; openmp-dev (openmp-...@lists.llvm.org)
> Subject: [llvm-dev] [5.0.0 Release] Only 3 release blockers left, please
> help fix!
> 
> Hello everyone,
> 
> We started the week with 32 open release blockers and are now down to only
> 3:
> https://bugs.llvm.org/buglist.cgi?f1=blocked=equals=33849_form
> at=advanced=---
> Many thanks for your hard work so far.
> 
> None of the three remaining ones have any traction, so any help would
> be much appreciated:
> 
> https://llvm.org/pr33668
> "Excessive memory and CPU use in tail duplication and associated
> passes due to critical edge splitting"
> Sounds like someone familiar with taildup is needed.
> 
> https://llvm.org/pr33930
> "Assertion `OpN.isUniqued() && "Only uniqued operands cannot be mapped
> immediately"' failed."
> Needs someone familiar with debug info.

See https://reviews.llvm.org/D37038 and comments from Adrian Prantl.
I hope to have time to look at this today, but can't guarantee results.
--paulr

> 
> https://llvm.org/pr33507
> "Assertion failed: Shift >= 0, file
> C:\src\llvm_package_303050\llvm\tools\clang\lib\Format\WhitespaceManager.c
> pp,
> line 245"
> clang-format asserts and breaks the correctness of some code. This
> seems bad. Needs someone familiar with clang-format.
> 
> If we can get these squashed, I'll be a very happy release manger.
> 
> Thanks,
> Hans
> ___
> 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

[lldb-dev] hang bug in lldb-mi -var-update

2017-08-25 Thread Ted Woodward via lldb-dev 
I found a hang in lldb-mi's -var-update. It checks to see if a var changed,
then it checks each of the children recursively. If a child is a pointer
back to a parent, as in this case:

struct complex_type
{
int i;
struct { long l; } inner;
struct complex_type *complex_ptr;
};

void
var_update_test(void)
{
struct complex_type complx_array[2];

complx_array[0].i = 4;
complx_array[0].inner.l = 4;
complx_array[0].complex_ptr = _array[1];
complx_array[1].i = 5;
complx_array[1].inner.l = 5;
complx_array[1].complex_ptr = _array[0];
 


the code in CMICmdCmdVarUpdate::ExamineSBValueForChange will get into an
infinite loop.

  const MIuint nChildren = vrwValue.GetNumChildren();
  for (MIuint i = 0; i < nChildren; ++i) {
lldb::SBValue member = vrwValue.GetChildAtIndex(i);
if (!member.IsValid())
  continue;

if (member.GetValueDidChange()) {
  vrwbChanged = true;
  return MIstatus::success;
} else if (ExamineSBValueForChange(member, vrwbChanged) && vrwbChanged)
  // Handle composite types (i.e. struct or arrays)
  return MIstatus::success;
  }

I've got a patch that disables checking a pointer's children. I'll put it up
on phabricator today.

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

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

2017-08-25 Thread Greg Clayton via lldb-dev 
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() 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(

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

2017-08-25 Thread 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 ==