[lldb-dev] [Bug 44430] TestSettings failures on Windows (array-of-strings vs arguments)

2020-03-05 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=44430

Tatyana Krasnukha  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||Tatyana.Krasnukha@synopsys.
   ||com
 Fixed By Commit(s)||a31130f6fcf27518b31a8ac1f59
   ||71a42fc24837e
 Status|NEW |RESOLVED

--- Comment #1 from Tatyana Krasnukha  ---
Seems to be fixed by https://reviews.llvm.org/D74903

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

[lldb-dev] [Bug 44432] TestSourceManager failure on Windows (unable to set breakpoint by absolute path)

2020-03-05 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=44432

Tatyana Krasnukha  changed:

   What|Removed |Added

 Fixed By Commit(s)||a31130f6fcf27518b31a8ac1f59
   ||71a42fc24837e
 CC||Tatyana.Krasnukha@synopsys.
   ||com
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from Tatyana Krasnukha  ---
Seems to be fixed by https://reviews.llvm.org/D74903

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

[lldb-dev] [Bug 45112] New: Tests import "lldb.macosx.heap" incorrectly

2020-03-05 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=45112

Bug ID: 45112
   Summary: Tests import "lldb.macosx.heap" incorrectly
   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: tatyana.krasnu...@synopsys.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

Tests API/lang/objc/ptr_refs/TestPtrRefsObjC.py and
API/functionalities/ptr_refs/TestPtrRefs.py (dwarf and gmodules) began to fail
after the commit that creates per-test debugger instead of using a global one
(https://reviews.llvm.org/D74903).

Looks like they require some settings that have default values now.

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

Re: [lldb-dev] [10.0.0 Release] Release Candidate 3 is here

2020-03-05 Thread Hans Wennborg via lldb-dev 
On Wed, Mar 4, 2020 at 2:49 PM Hans Wennborg  wrote:
>
> Hello everyone,
>
> It took a bit longer than planned, but Release Candidate 3 is now
> here. It was tagged as llvmorg-10.0.0-rc3 on the release branch at
> 3a843031a5 and contains 95 commits since the previous release
> candidate.
>
> If no new problems arise, this is what the final release will look like.
>
> Source code and docs are available at
> https://prereleases.llvm.org/10.0.0/#rc3 and
> https://github.com/llvm/llvm-project/releases/tag/llvmorg-10.0.0-rc3
>
> Pre-built binaries will be added as they become ready.
>
> Please file bug reports for any issues you find as blockers of
> https://llvm.org/pr44555
>
> Release testers, please run the test script, share your results, and
> upload binaries.

Windows is ready:

$ sha256sum LLVM*.exe
18503a67b217ad74dc08e73175dafeb24a7a6050e6307d3ec90cd945790d7881
LLVM-10.0.0-rc3-win32.exe
5408e4fb41b4d25c252f8c061e38c74f1dcf4dea999d0a05115255f30e8d5ca6
LLVM-10.0.0-rc3-win64.exe

They were built with the attached batch file.


build_llvm_1000-rc3._bat_
Description: Binary data
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [10.0.0 Release] Release Candidate 3 is here

2020-03-05 Thread Hans Wennborg via lldb-dev 
On Wed, Mar 4, 2020 at 2:49 PM Hans Wennborg  wrote:
>
> Hello everyone,
>
> It took a bit longer than planned, but Release Candidate 3 is now
> here. It was tagged as llvmorg-10.0.0-rc3 on the release branch at
> 3a843031a5 and contains 95 commits since the previous release
> candidate.
>
> If no new problems arise, this is what the final release will look like.
>
> Source code and docs are available at
> https://prereleases.llvm.org/10.0.0/#rc3 and
> https://github.com/llvm/llvm-project/releases/tag/llvmorg-10.0.0-rc3

There seems to be issues with a patch that landed just before the tag
(bdad0a1). If you were planning to test rc3 but didn't start yet, you
may want to hold off until this is fixed and released as rc4.
Hopefully that can happen soon.

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

Re: [lldb-dev] [Release-testers] [10.0.0 Release] Release Candidate 3 is here

2020-03-05 Thread Michał Górny via lldb-dev 
On Wed, 2020-03-04 at 14:49 +0100, Hans Wennborg via Release-testers
wrote:
> Hello everyone,
> 
> It took a bit longer than planned, but Release Candidate 3 is now
> here. It was tagged as llvmorg-10.0.0-rc3 on the release branch at
> 3a843031a5 and contains 95 commits since the previous release
> candidate.
> 
> If no new problems arise, this is what the final release will look like.
> 

This one looks good from Gentoo perspective (or well, as good as we can
expect it to be ;-)).  The only problem I can see is the usual LLDB
status.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [10.0.0 Release] Release Candidate 3 is here

2020-03-05 Thread Brian Cain via lldb-dev 
Uploaded Ubuntu 18.04 binaries:
7ebc00479d05772e56c34c1b0f40295af2dd4a6b165d9107946ff2cdb7c219ac
 clang+llvm-10.0.0-rc3-x86_64-linux-gnu-ubuntu-18.04.tar.xz

On Wed, Mar 4, 2020 at 7:49 AM Hans Wennborg via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> Hello everyone,
>
> It took a bit longer than planned, but Release Candidate 3 is now
> here. It was tagged as llvmorg-10.0.0-rc3 on the release branch at
> 3a843031a5 and contains 95 commits since the previous release
> candidate.
>
> If no new problems arise, this is what the final release will look like.
>
> Source code and docs are available at
> https://prereleases.llvm.org/10.0.0/#rc3 and
> https://github.com/llvm/llvm-project/releases/tag/llvmorg-10.0.0-rc3
>
> Pre-built binaries will be added as they become ready.
>
> Please file bug reports for any issues you find as blockers of
> https://llvm.org/pr44555
>
> Release testers, please run the test script, share your results, and
> upload binaries.
>
> Thanks,
> Hans
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


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

Re: [lldb-dev] [llvm-dev] [10.0.0 Release] Release Candidate 3 is here

2020-03-05 Thread Hans Wennborg via lldb-dev 
Thanks! Added.

On Thu, Mar 5, 2020 at 3:15 PM Brian Cain  wrote:
>
> Uploaded Ubuntu 18.04 binaries:
> 7ebc00479d05772e56c34c1b0f40295af2dd4a6b165d9107946ff2cdb7c219ac  
> clang+llvm-10.0.0-rc3-x86_64-linux-gnu-ubuntu-18.04.tar.xz
>
> On Wed, Mar 4, 2020 at 7:49 AM Hans Wennborg via llvm-dev 
>  wrote:
>>
>> Hello everyone,
>>
>> It took a bit longer than planned, but Release Candidate 3 is now
>> here. It was tagged as llvmorg-10.0.0-rc3 on the release branch at
>> 3a843031a5 and contains 95 commits since the previous release
>> candidate.
>>
>> If no new problems arise, this is what the final release will look like.
>>
>> Source code and docs are available at
>> https://prereleases.llvm.org/10.0.0/#rc3 and
>> https://github.com/llvm/llvm-project/releases/tag/llvmorg-10.0.0-rc3
>>
>> Pre-built binaries will be added as they become ready.
>>
>> Please file bug reports for any issues you find as blockers of
>> https://llvm.org/pr44555
>>
>> Release testers, please run the test script, share your results, and
>> upload binaries.
>>
>> Thanks,
>> Hans
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> --
> -Brian
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Continuing from dbgtrap on different targets

2020-03-05 Thread Jim Ingham via lldb-dev 
BTW, I think the better way to handle this in lldb is not to move the PC past 
the trap when you stop, but that when CONTINUING past a trap that we don't 
recognize, we always make sure we start past the trap.  That way it won't look 
weird when people compare crash logs coming from hitting a trap with backtraces 
in lldb, but we would still get the desired behavior.

Jim


> On Mar 4, 2020, at 11:29 PM, Pavel Labath  wrote:
> 
> On 04/03/2020 21:45, Jim Ingham via llvm-dev wrote:
>> As you have seen, different machine architectures do different things after 
>> hitting a trap.  On x86_64, the trap instruction is executed, and then you 
>> stop, so the PC is left after the stop.  On arm64, when execution halts the 
>> pc is still pointing at the trap instruction.
>> 
>> I don't think lldb should be in the business of telling systems how they 
>> should report stops, especially since that is certainly something we can 
>> handle in lldb.
>> 
>> For traps that lldb recognizes as ones it is using for breakpoints, it 
>> already has to handle this difference for you.  But for traps we know 
>> nothing about we don't do anything special. 
>> 
>> I think it would be entirely reasonable that whenever lldb encounters a trap 
>> instruction that isn't one of ours it should always move the PC after the 
>> trap before returning control to the user.  I can't see why you would want 
>> to keep hitting the trap over and over.  I've received several bugs (on the 
>> Apple bug reporter side) for this feature.  This might be something we teach 
>> lldb-server & debugserver to do, rather than lldb but that's an 
>> implementation detail...
>> 
>> For now, on architectures where the trap doesn't execute, you just need to 
>> move the pc past the trap by hand (with the "thread jump" command) before 
>> continuing.  That has always been safe on arm64 so far as I can tell.
>> 
>> Jim
> 
> Yes, this is something that has bugged me too.
> 
> While I think it would be nice if the OSes hid these architecture quirks
> (hell, I think it would be nice if the CPU manufacturers made this
> consistent so that the OS doesn't need to hide it), I think that
> changing that at this point is very unlikely, and so working around it
> in lldb is probably the best we can do.
> 
> I am not sure what is the official position on continuing from a debug
> trap, but I think that without that ability, the concept would be pretty
> useless. A quick example  shows that clang
> produces the "expected" output even at -O3. In fact, on aarch64,
> __builtin_debugtrap() and __builtin_trap() produce the same instruction,
> and the only difference between them is that the latter also triggers
> DCE of everything coming after it.
> 
> pl

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

Re: [lldb-dev] [llvm-dev] Continuing from dbgtrap on different targets

2020-03-05 Thread Jim Ingham via lldb-dev 
That shouldn't be too hard to do.  We already have machinery to inject a "step 
over breakpoint trap" ThreadPlan when we continue, so we could use the same 
detection point to just move the PC before continuing in the case of an 
unrecognized trap.

Jim


> On Mar 5, 2020, at 10:10 AM, Jim Ingham via lldb-dev 
>  wrote:
> 
> BTW, I think the better way to handle this in lldb is not to move the PC past 
> the trap when you stop, but that when CONTINUING past a trap that we don't 
> recognize, we always make sure we start past the trap.  That way it won't 
> look weird when people compare crash logs coming from hitting a trap with 
> backtraces in lldb, but we would still get the desired behavior.
> 
> Jim
> 
> 
>> On Mar 4, 2020, at 11:29 PM, Pavel Labath  wrote:
>> 
>> On 04/03/2020 21:45, Jim Ingham via llvm-dev wrote:
>>> As you have seen, different machine architectures do different things after 
>>> hitting a trap.  On x86_64, the trap instruction is executed, and then you 
>>> stop, so the PC is left after the stop.  On arm64, when execution halts the 
>>> pc is still pointing at the trap instruction.
>>> 
>>> I don't think lldb should be in the business of telling systems how they 
>>> should report stops, especially since that is certainly something we can 
>>> handle in lldb.
>>> 
>>> For traps that lldb recognizes as ones it is using for breakpoints, it 
>>> already has to handle this difference for you.  But for traps we know 
>>> nothing about we don't do anything special. 
>>> 
>>> I think it would be entirely reasonable that whenever lldb encounters a 
>>> trap instruction that isn't one of ours it should always move the PC after 
>>> the trap before returning control to the user.  I can't see why you would 
>>> want to keep hitting the trap over and over.  I've received several bugs 
>>> (on the Apple bug reporter side) for this feature.  This might be something 
>>> we teach lldb-server & debugserver to do, rather than lldb but that's an 
>>> implementation detail...
>>> 
>>> For now, on architectures where the trap doesn't execute, you just need to 
>>> move the pc past the trap by hand (with the "thread jump" command) before 
>>> continuing.  That has always been safe on arm64 so far as I can tell.
>>> 
>>> Jim
>> 
>> Yes, this is something that has bugged me too.
>> 
>> While I think it would be nice if the OSes hid these architecture quirks
>> (hell, I think it would be nice if the CPU manufacturers made this
>> consistent so that the OS doesn't need to hide it), I think that
>> changing that at this point is very unlikely, and so working around it
>> in lldb is probably the best we can do.
>> 
>> I am not sure what is the official position on continuing from a debug
>> trap, but I think that without that ability, the concept would be pretty
>> useless. A quick example  shows that clang
>> produces the "expected" output even at -O3. In fact, on aarch64,
>> __builtin_debugtrap() and __builtin_trap() produce the same instruction,
>> and the only difference between them is that the latter also triggers
>> DCE of everything coming after it.
>> 
>> pl
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

Re: [lldb-dev] I wanna work on the open project "Add support for batch-testing to the LLDB testsuite."

2020-03-05 Thread Jim Ingham via lldb-dev 
Glad to hear from you.  I am:

jing...@apple.com

Jim


> On Mar 3, 2020, at 10:11 AM, SREENIVASA SUMADITHYA - IIITK via lldb-dev 
>  wrote:
> 
> I wanna work on the open project "Add support for batch-testing to the LLDB 
> testsuite." for google summer of code
> Can I get more details on that?
> Can I get a contact for the confirmed mentor, Jim Ingham?
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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