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
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
On 24 Aug 2017, at 23:48, Hans Wennborg wrote:
>
> On Mon, Aug 14, 2017 at 3:36 AM, Dimitry Andric wrote:
>> On 11 Aug 2017, at 04:00, Hans Wennborg via Release-testers
>> wrote:
>>> 5.0.0-rc2 was just tagged.
>>>
>>> I know we still have a bunch of open release blockers, but there has
>>> be
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 suspec
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_
> -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
> -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 Relea
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, 2
The spec says that's what it should do. From
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Variable-Objects.html :
"Reevaluate the expressions corresponding to the variable object name and
all its direct and indirect children, and return the list of variable
objects whose values have change
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 re
If that’s the expectation, you have to obey it... Xcode is pretty careful to
only act on the elements that were visible in a view, which made the locals
view much less heavy-weight. But that took some work on their end.
More to the point, this doesn’t seem to be code that should be in the MI
11 matches
Mail list logo
