Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 3 tagged

2018-02-23 Thread Brian Cain via lldb-dev 
SLES11 binaries for rc3 uploaded.

55b63de8adc12c67eb11abcf1a5f7132cca59b4e
clang+llvm-6.0.0-rc3-x86_64-linux-sles11.3.tar.xz


On Fri, Feb 23, 2018 at 9:14 AM, Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:

> Dear testers,
>
> 6.0.0-rc3 was just tagged, after r325901 on the branch.
>
> There are still a few open blockers, but I'm not sure we'll actually
> end up blocking on all of them. So depending on what comes up, this
> release candidate is probably pretty close to what the final release
> will look like (I'm still hoping for more release notes, though).
>
> I'm hoping we can get to 'final' sometime next week.
>
> Please test, let me know how it goes, and upload binaries.
>
> Thanks,
> Hans
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>



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

Re: [lldb-dev] Current state of the unit tests

2018-02-23 Thread Vedant Kumar via lldb-dev 

> On Feb 23, 2018, at 3:17 PM, Vedant Kumar via lldb-dev 
>  wrote:
> 
> Hi,
> 
> At the moment, I'm seeing two issues with the unit tests on my machine.
> 
> First, TestBase.LaunchModePreservesEnvironment is failing:
> 
>> [ RUN  ] TestBase.LaunchModePreservesEnvironment
>> /Users/vsk/src/llvm.org-lldbsan/llvm/tools/lldb/unittests/tools/lldb-server/tests/LLGSTest.cpp:30:
>>  Failure
>> Value of: 
>> llvm::detail::TakeExpected(Client.GetLatestStopReplyAs())
>> Expected: succeeded with value (is an object whose given property is equal 
>> to 2-byte object <00-00>)
>>  Actual: succeeded with value 16-byte object <10-60 A7-04 01-00 00-00 01-00 
>> 00-00 00-00 00-30>, whose given property is 2-byte object <00-01>(is an 
>> object whose given property isn't equal to 2-byte object <00-00>)
>> [  FAILED  ] TestBase.LaunchModePreservesEnvironment (67 ms)
> 
> I filed https://bugs.llvm.org/show_bug.cgi?id=36494 to track the issue.

^ This issue is resolved now with a cmake fix.


> Second, TestClient::SendMessage is generating quite a lot of "INFO" output 
> which clutters up the terminal. Pavel, would you mind if I removed this 
> logging?

^ I'll let Pavel decide the best way to deal with this one.

vedant

> 
> thanks,
> vedant
> ___
> 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] Current state of the unit tests

2018-02-23 Thread Pavel Labath via lldb-dev 
On 23 February 2018 at 16:19, Adrian McCarthy  wrote:
> I'm also seeing windows appear and quickly vanish a several times while
> running the lit tests.

That's because the tests run inferiors and lldb on windows will always
run them in a separate console window. IIRC, there is a special hack
in dotest, which prevents opening windows for testing. You probably
need something like that for lit tests as well.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Current state of the unit tests

2018-02-23 Thread Pavel Labath via lldb-dev 
Yeah, if a lit test fails, the dotest tests will not get run. That is
fine, but having a target which only runs dotest tests would probably
be nice as well.

On 23 February 2018 at 16:15, Vedant Kumar  wrote:
> check-lldb-lit should just be a dependency of check-lldb, so the dotest.py
> tests should still run.
>
> Are one of the lit tests failing? That might explain why subsequent tests
> aren't run.
>
> vedant
>
> On Feb 23, 2018, at 4:13 PM, Adrian McCarthy  wrote:
>
> As of this afternoon, it seems ninja check-lldb runs only the lit tests and
> not the dotest.py tests.  Was this an intentional change?
>
> On Fri, Feb 23, 2018 at 3:36 PM, Vedant Kumar via lldb-dev
>  wrote:
>>
>> Cool, I'll work up a patch for this.
>>
>> And thanks for commenting on PR36494, I'm testing a fix out right now :).
>>
>> vedant
>>
>> On Feb 23, 2018, at 3:35 PM, Pavel Labath  wrote:
>>
>> On 23 February 2018 at 15:17, Vedant Kumar  wrote:
>>
>> Second, TestClient::SendMessage is generating quite a lot of "INFO" output
>> which clutters up the terminal. Pavel, would you mind if I removed this
>> logging?
>>
>>
>> Yeah, we should probably do that. The idea here was that the packet
>> log would provide you with additional context for the situation when
>> the test fails, but it *is* very verbose. I'll have to come up with a
>> better solution for error reporting here.
>>
>>
>>
>> ___
>> 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] [Bug 36494] TestBase.LaunchModePreservesEnvironment is failing on Darwin

2018-02-23 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=36494

Vedant Kumar  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Vedant Kumar  ---
Great, I implemented your suggestion in r326001.

-- 
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] Current state of the unit tests

2018-02-23 Thread Adrian McCarthy via lldb-dev 
Actually, it appears one of the lit tests is unexpectedly passing:

Unexpected Passing Tests (1):
lldb :: Expr/TestCallStdStringFunction.test

lit then returns an error code, and ninja bails before starting the
dotest.py tests:

FAILED: cmd.exe /C "cd /D D:\src\llvm\build\mono\tools\lldb\lit &&
C:\python_35\python_d.exe D:/src/llvm/build/mono/./bin/llvm-lit.py -sv
--param lldb_site_config=D:/src/llvm/build/mono/tools/lldb/lit/lit.site.cfg
--param
lldb_unit_site_config=D:/src/llvm/build/mono/tools/lldb/lit/Unit/lit.site.cfg
D:/src/llvm/build/mono/tools/lldb/lit"
ninja: build stopped: subcommand failed.

I'm also seeing windows appear and quickly vanish a several times while
running the lit tests.

On Fri, Feb 23, 2018 at 4:15 PM, Vedant Kumar  wrote:

> check-lldb-lit should just be a dependency of check-lldb, so the dotest.py
> tests should still run.
>
> Are one of the lit tests failing? That might explain why subsequent tests
> aren't run.
>
> vedant
>
> On Feb 23, 2018, at 4:13 PM, Adrian McCarthy  wrote:
>
> As of this afternoon, it seems ninja check-lldb runs *only* the lit tests
> and not the dotest.py tests.  Was this an intentional change?
>
> On Fri, Feb 23, 2018 at 3:36 PM, Vedant Kumar via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Cool, I'll work up a patch for this.
>>
>> And thanks for commenting on PR36494, I'm testing a fix out right now :).
>>
>> vedant
>>
>> On Feb 23, 2018, at 3:35 PM, Pavel Labath  wrote:
>>
>> On 23 February 2018 at 15:17, Vedant Kumar  wrote:
>>
>> Second, TestClient::SendMessage is generating quite a lot of "INFO"
>> output which clutters up the terminal. Pavel, would you mind if I removed
>> this logging?
>>
>>
>> Yeah, we should probably do that. The idea here was that the packet
>> log would provide you with additional context for the situation when
>> the test fails, but it *is* very verbose. I'll have to come up with a
>> better solution for error reporting here.
>>
>>
>>
>> ___
>> 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] Current state of the unit tests

2018-02-23 Thread Vedant Kumar via lldb-dev 
check-lldb-lit should just be a dependency of check-lldb, so the dotest.py 
tests should still run.

Are one of the lit tests failing? That might explain why subsequent tests 
aren't run.

vedant

> On Feb 23, 2018, at 4:13 PM, Adrian McCarthy  wrote:
> 
> As of this afternoon, it seems ninja check-lldb runs only the lit tests and 
> not the dotest.py tests.  Was this an intentional change?
> 
> On Fri, Feb 23, 2018 at 3:36 PM, Vedant Kumar via lldb-dev 
> > wrote:
> Cool, I'll work up a patch for this.
> 
> And thanks for commenting on PR36494, I'm testing a fix out right now :).
> 
> vedant
> 
>> On Feb 23, 2018, at 3:35 PM, Pavel Labath > > wrote:
>> 
>> On 23 February 2018 at 15:17, Vedant Kumar > > wrote:
>>> Second, TestClient::SendMessage is generating quite a lot of "INFO" output 
>>> which clutters up the terminal. Pavel, would you mind if I removed this 
>>> logging?
>>> 
>> 
>> Yeah, we should probably do that. The idea here was that the packet
>> log would provide you with additional context for the situation when
>> the test fails, but it *is* very verbose. I'll have to come up with a
>> better solution for error reporting here.
> 
> 
> ___
> 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] Current state of the unit tests

2018-02-23 Thread Adrian McCarthy via lldb-dev 
As of this afternoon, it seems ninja check-lldb runs *only* the lit tests
and not the dotest.py tests.  Was this an intentional change?

On Fri, Feb 23, 2018 at 3:36 PM, Vedant Kumar via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Cool, I'll work up a patch for this.
>
> And thanks for commenting on PR36494, I'm testing a fix out right now :).
>
> vedant
>
> On Feb 23, 2018, at 3:35 PM, Pavel Labath  wrote:
>
> On 23 February 2018 at 15:17, Vedant Kumar  wrote:
>
> Second, TestClient::SendMessage is generating quite a lot of "INFO" output
> which clutters up the terminal. Pavel, would you mind if I removed this
> logging?
>
>
> Yeah, we should probably do that. The idea here was that the packet
> log would provide you with additional context for the situation when
> the test fails, but it *is* very verbose. I'll have to come up with a
> better solution for error reporting here.
>
>
>
> ___
> 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] Current state of the unit tests

2018-02-23 Thread Vedant Kumar via lldb-dev 
Cool, I'll work up a patch for this.

And thanks for commenting on PR36494, I'm testing a fix out right now :).

vedant

> On Feb 23, 2018, at 3:35 PM, Pavel Labath  wrote:
> 
> On 23 February 2018 at 15:17, Vedant Kumar  wrote:
>> Second, TestClient::SendMessage is generating quite a lot of "INFO" output 
>> which clutters up the terminal. Pavel, would you mind if I removed this 
>> logging?
>> 
> 
> Yeah, we should probably do that. The idea here was that the packet
> log would provide you with additional context for the situation when
> the test fails, but it *is* very verbose. I'll have to come up with a
> better solution for error reporting here.

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

Re: [lldb-dev] Current state of the unit tests

2018-02-23 Thread Pavel Labath via lldb-dev 
On 23 February 2018 at 15:17, Vedant Kumar  wrote:
> Second, TestClient::SendMessage is generating quite a lot of "INFO" output 
> which clutters up the terminal. Pavel, would you mind if I removed this 
> logging?
>

Yeah, we should probably do that. The idea here was that the packet
log would provide you with additional context for the situation when
the test fails, but it *is* very verbose. I'll have to come up with a
better solution for error reporting here.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Test fails with mutex lock fail?

2018-02-23 Thread Ted Woodward via lldb-dev 
Has anyone seen anything like this?

RESULT: PASSED (1 passes, 0 failures, 0 errors, 0 skipped, 0 expected
failures, 0 unexpected successes)
terminating with uncaught exception of type std::__1::system_error: mutex
lock failed: Invalid argument
[TestDataFormatterVarScriptFormatting.py FAILED]

It shows up occasionally on our buildbot runs, on different tests. I've
never seen it when running locally.

--
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] Current state of the unit tests

2018-02-23 Thread Vedant Kumar via lldb-dev 
Hi,

At the moment, I'm seeing two issues with the unit tests on my machine.

First, TestBase.LaunchModePreservesEnvironment is failing:

> [ RUN  ] TestBase.LaunchModePreservesEnvironment
> /Users/vsk/src/llvm.org-lldbsan/llvm/tools/lldb/unittests/tools/lldb-server/tests/LLGSTest.cpp:30:
>  Failure
> Value of: 
> llvm::detail::TakeExpected(Client.GetLatestStopReplyAs())
> Expected: succeeded with value (is an object whose given property is equal to 
> 2-byte object <00-00>)
>   Actual: succeeded with value 16-byte object <10-60 A7-04 01-00 00-00 01-00 
> 00-00 00-00 00-30>, whose given property is 2-byte object <00-01>(is an 
> object whose given property isn't equal to 2-byte object <00-00>)
> [  FAILED  ] TestBase.LaunchModePreservesEnvironment (67 ms)

I filed https://bugs.llvm.org/show_bug.cgi?id=36494 to track the issue.

Second, TestClient::SendMessage is generating quite a lot of "INFO" output 
which clutters up the terminal. Pavel, would you mind if I removed this logging?

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

[lldb-dev] [Bug 36494] New: TestBase.LaunchModePreservesEnvironment is failing on Darwin

2018-02-23 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=36494

Bug ID: 36494
   Summary: TestBase.LaunchModePreservesEnvironment is failing on
Darwin
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: v...@apple.com
CC: llvm-b...@lists.llvm.org

With r325964, I see:

[ RUN  ] TestBase.LaunchModePreservesEnvironment
/Users/vsk/src/llvm.org-lldbsan/llvm/tools/lldb/unittests/tools/lldb-server/tests/LLGSTest.cpp:30:
Failure
Value of:
llvm::detail::TakeExpected(Client.GetLatestStopReplyAs())
Expected: succeeded with value (is an object whose given property is equal to
2-byte object <00-00>)
  Actual: succeeded with value 16-byte object <10-60 A7-04 01-00 00-00 01-00
00-00 00-00 00-30>, whose given property is 2-byte object <00-01>(is an object
whose given property isn't equal to 2-byte object <00-00>)
[  FAILED  ] TestBase.LaunchModePreservesEnvironment (67 ms)

The public Darwin bots are failing in the same way, but curiously still appear
'green'.

-- 
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] problem with TestLoadUnload.py

2018-02-23 Thread Pavel Labath via lldb-dev 
A couple of things here:
- there should be no performance difference between doing build in
setUp and the test function as setUp is called once per test function
- my change was to run have the paralelization at a file level
(previously it was at folder-level). All test functions in a single
file are still run serially.
- also, why do we need libgen.h in the test in the first place? Can we
just remove that?

So, right now it should be possible to move the build call into the
test function without negatively impacting much of anything. However,
I would like it if we can move towards a world, where we can do more
stuff in the setUp() function (or even setUpTestCase()), as that what
they were meant for -- setting up state which is common for multiple
tests. One way to achieve this would be to resurrect our ability to
@skip an entire test class. Right now the situation is that some of
our decorators work on class level, but most of them don't. I don't
think it should not be too hard to fix the decorators to work at class
level as well. Then if the whole test class does not apply in some
situation, we can @skip the whole class and avoid even running the
setUp code.

WDYT?


On 23 February 2018 at 13:08, Ted Woodward  wrote:
> I tried to put @skipIf(...) before setUp, but it didn't work. Currently I
> have the build inside an if, checking for Hexagon. We don't support this use
> of shared libraries, so all tests are skipped.
>
> I certainly don't want to build the testcase 6 times, given that we're
> moving away from that! But we need some general way to skip the build for
> systems that can't build a given testcase. I have many tests skipped when
> running without an OS, because we don't support c++11 in that mode.
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>> -Original Message-
>> From: apra...@apple.com [mailto:apra...@apple.com]
>> Sent: Friday, February 23, 2018 2:47 PM
>> To: Ted Woodward 
>> Cc: Pavel Labath 
>> Subject: Re: problem with TestLoadUnload.py
>>
>>
>>
>> > On Feb 23, 2018, at 12:08 PM, Ted Woodward
>>  wrote:
>> >
>> > Hi Adrian,
>> >
>> > In r324368 you changed TestLoadUnload.py to do a build in the setUp
>> > function. This seems to be called before the actual testcases are
>> > checked, so a skipped testcase would still call setUp and do the
>> > build. If the build fails (say, on systems that don't have libgen.h),
>> > the test errors out before it can be skipped.
>> >
>> > Would you mind moving the build into each testcase?
>>
>> +Pavel
>>
>> I'm afraid that would cause quite a performance degradation in the case
> where
>> the test is not skipped wince we then need to build the test once for each
> test
>> function. On the other hand since Pavel's change to run each test function
> in
>> parallel we are presumably building the test once per test function
> anyway, so
>> this should not be any more expensive.
>>
>> That said, I wonder if the right solution for your problem wouldn't be to
> not run
>> setUp if the test depending on it is skipped.
>>
>> (Do you mind if I add lldb-dev to the CC list?)
>>
>> -- adrian
>>
>> > Thanks,
>> >
>> > 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] [Bug 36435] Unexpected conditional breakpoint hit

2018-02-23 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=36435

Jim Ingham  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #3 from Jim Ingham  ---
Ack, that's my bad.  Fixed in r325958.

Thanks for reporting this!

-- 
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] problem with TestLoadUnload.py

2018-02-23 Thread Ted Woodward via lldb-dev 
I tried to put @skipIf(...) before setUp, but it didn't work. Currently I
have the build inside an if, checking for Hexagon. We don't support this use
of shared libraries, so all tests are skipped.

I certainly don't want to build the testcase 6 times, given that we're
moving away from that! But we need some general way to skip the build for
systems that can't build a given testcase. I have many tests skipped when
running without an OS, because we don't support c++11 in that mode.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

> -Original Message-
> From: apra...@apple.com [mailto:apra...@apple.com]
> Sent: Friday, February 23, 2018 2:47 PM
> To: Ted Woodward 
> Cc: Pavel Labath 
> Subject: Re: problem with TestLoadUnload.py
> 
> 
> 
> > On Feb 23, 2018, at 12:08 PM, Ted Woodward
>  wrote:
> >
> > Hi Adrian,
> >
> > In r324368 you changed TestLoadUnload.py to do a build in the setUp
> > function. This seems to be called before the actual testcases are
> > checked, so a skipped testcase would still call setUp and do the
> > build. If the build fails (say, on systems that don't have libgen.h),
> > the test errors out before it can be skipped.
> >
> > Would you mind moving the build into each testcase?
> 
> +Pavel
> 
> I'm afraid that would cause quite a performance degradation in the case
where
> the test is not skipped wince we then need to build the test once for each
test
> function. On the other hand since Pavel's change to run each test function
in
> parallel we are presumably building the test once per test function
anyway, so
> this should not be any more expensive.
> 
> That said, I wonder if the right solution for your problem wouldn't be to
not run
> setUp if the test depending on it is skipped.
> 
> (Do you mind if I add lldb-dev to the CC list?)
> 
> -- adrian
> 
> > Thanks,
> >
> > 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] [Bug 36490] Segmentation fault when accessing any Python script object

2018-02-23 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=36490

lab...@google.com changed:

   What|Removed |Added

 CC||lab...@google.com
 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #3 from lab...@google.com ---
3.6 is ancient. There isn't anything we could do about your crash even if we
found the cause (also, 3.6 had plenty of other issues as well).

I'd recommend trying a newer version of the debugger, 3.8 at the very least.

-- 
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] [6.0.0 Release] Release notes nag email

2018-02-23 Thread Alexander Kornienko via lldb-dev 
On Wed, Feb 21, 2018 at 4:48 PM Hans Wennborg  wrote:

>
> Alex: There seems to be good release notes for clang-tidy, but do you
> know if there should be notes for the others tools? Who are the right
> people to ping about this?
>

Adding folks responsible for clangd and some other tools.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB gcc std lib data formatters

2018-02-23 Thread Bryan Bennetts via lldb-dev 
Ah, ok so the default DWARF version for g++ 5 (and 6) is 2, compiling with
-gdwarf-3 solves my problem.

Thanks for the help,

Bryan.

On Thu, 22 Feb 2018 at 17:02 Greg Clayton  wrote:

>
>
> On Feb 19, 2018, at 1:51 AM, Bryan Bennetts via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi,
>
> Apologies if this is  the wrong forum for this question - redirection to
> the correct place would be appreciated...
>
> I am running
>
> lldb --version
> lldb-900.0.64
>   Swift-4.0
>
> with binaries compiled using g++
>
> g++-5 --version
> g++-5 (Homebrew GCC 5.5.0_2) 5.5.0
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.(although I have tried a build from repo as well)
>
>
> The website  implies that gcc std
> library formatters should be available:
>
> By default, several categories are created in LLDB:
>
>- default: this is the category where every formatter ends up, unless
>another category is specified
>- objc: formatters for basic and common Objective-C types that do not
>specifically depend on Mac OS X
>- gnu-libstdc++: formatters for std::string, std::vector, std::list
>and std::map as implemented by libstdcpp
>
> However I see:
>
> (lldb) type category list
>
>Category: default (enabled)
> Category: VectorTypes (enabled, applicable for language(s): objective-c++)
> Category: runtime-synthetics (enabled, applicable for language(s):
> objective-c++, swift)
> Category: system (enabled, applicable for language(s): objective-c++)
> (lldb) type category enable gnu-libstdc++
>
>warning: empty category enabled (typo?)
>
> And the std containers do not print nicely:
>
> containerTest: cat main.cpp
> #include 
> #include 
>
> using namespace std;
>
> int main()
> {
> auto v = vector< unsigned >{ 0, 1, 2, 3, 4, 5, 6, 7, 9 };
>
> for( auto i : v )
> {
> cout << i << "\n";
> }
>
> return( 0 );
> }
>  containerTest: g++-5 -g -std=c++11  main.cpp
> /var/folders/2_/07xjgwq904376gst9m3ddb10gn/T//cctjpiwL.s:157:11:
> warning: section "__textcoal_nt" is deprecated
> .section __TEXT,__textcoal_nt,coalesced,pure_instructions
>  ^  ~
> /var/folders/2_/07xjgwq904376gst9m3ddb10gn/T//cctjpiwL.s:157:11: note:
> change section name to "__text"
> .section __TEXT,__textcoal_nt,coalesced,pure_instructions
>  ^  ~
> /var/folders/2_/07xjgwq904376gst9m3ddb10gn/T//cctjpiwL.s:386:11:
> warning: section "__textcoal_nt" is deprecated
> .section __TEXT,__textcoal_nt,coalesced,pure_instructions
>  ^  ~
> /var/folders/2_/07xjgwq904376gst9m3ddb10gn/T//cctjpiwL.s:386:11: note:
> change section name to "__text"
> .section __TEXT,__textcoal_nt,coalesced,pure_instructions
>  ^  ~
> /var/folders/2_/07xjgwq904376gst9m3ddb10gn/T//cctjpiwL.s:430:11:
> warning: section "__textcoal_nt" is deprecated
> .section __TEXT,__textcoal_nt,coalesced,pure_instructions
>  ^  ~
> /var/folders/2_/07xjgwq904376gst9m3ddb10gn/T//cctjpiwL.s:430:11: note:
> change section name to "__text"
> .section __TEXT,__textcoal_nt,coalesced,pure_instructions
>  ^  ~
> /var/folders/2_/07xjgwq904376gst9m3ddb10gn/T//cctjpiwL.s:683:11:
> warning: section "__textcoal_nt" is deprecated
> .section __TEXT,__textcoal_nt,coalesced,pure_instructions
>  ^  ~
> /var/folders/2_/07xjgwq904376gst9m3ddb10gn/T//cctjpiwL.s:683:11: note:
> change section name to "__text"
> .section __TEXT,__textcoal_nt,coalesced,pure_instructions
>  ^  ~
>  containerTest: lldb ./a.out
> (lldb) target create "./a.out"
> Current executable set to './a.out' (x86_64).
> (lldb) b main
> Breakpoint 1: where = a.out`main + 13 at main.cpp:8, address =
> 0x00011673
> (lldb) run
> Process 98294 launched: './a.out' (x86_64)
> Process 98294 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
> frame #0: 0x00011673 a.out`main at main.cpp:8
>5
>6int main()
>7{
> -> 8auto v = vector< unsigned >{ 0, 1, 2, 3, 4, 5, 6, 7, 9 };
>9
>10  for( auto i : v )
>11  {
> Target 0: (a.out) stopped.
> (lldb) n
> Process 98294 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = step over
> frame #0: 0x000116bd a.out`main at main.cpp:10
>7{
>8auto v = vector< unsigned >{ 0, 1, 2, 3, 4, 5, 6, 7, 9 };
>9
> -> 10  for( auto i : v )
>11  {
>12  cout << i << "\n";
>13  }
> Target 0: (a.out) stopped.
> (lldb) p v
> (vector >) $0 = {
>