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

2020-02-18 Thread Dimitry Andric via lldb-dev
On 13 Feb 2020, at 23:34, Hans Wennborg via Release-testers 
 wrote:
> 
> Release Candidate 2 was tagged earlier today as llvmorg-10.0.0-rc2. It
> includes 98 commits since the previous release candidate.

For this rc, I used three patches, which are attached.

Main results on amd64-freebsd11:

  Expected Passes: 67927
  Expected Failures  : 266
  Unsupported Tests  : 4654
  Unexpected Passes  : 5
  Unexpected Failures: 539
  Individual Timeouts: 19

Main results on i386-freebsd11:

  Expected Passes: 64981
  Passes With Retry  : 1
  Expected Failures  : 249
  Unsupported Tests  : 3083
  Unresolved Tests   : 1
  Unexpected Passes  : 5
  Unexpected Failures: 231
  Individual Timeouts: 9

Uploaded:
SHA256 (clang+llvm-10.0.0-rc2-amd64-unknown-freebsd11.tar.xz) = 
5d2be46c05f1db55391caec2abfea2558121eaed41ab586281555a0f337e3e1b
SHA256 (clang+llvm-10.0.0-rc2-i386-unknown-freebsd11.tar.xz) = 
203e45a8ded937a6fc2859475329bad1e336676bfc3ad693f96ad52d3693b2ed

On both amd64 and i386, the test-suite build still segfaults (and even
results in one clang-10 process hanging at 100% CPU), which is tracked
in https://bugs.llvm.org/show_bug.cgi?id=44763.

-Dimitry


fix-clang-1.diff
Description: Binary data


fix-compiler-rt-1.diff
Description: Binary data


fix-test-suite-1.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] queue-name parameter

2020-02-18 Thread Fernando Bunn via lldb-dev
Jim,
filed here: FB7587703 (better late than never I guess)

thanks :)

--
Fernando



On Mon, Jul 22, 2019 at 6:18 PM Jim Ingham  wrote:

> I already filed both of these issues with Apple.  If you want to file them
> too, feel free.  I'll dup them to the ones I filed but that way you will
> get notification when they get fixed.  These are also general lldb issues,
> so it would be good to file something with http://bugs.llvm.org.
>
> Jim
>
>
> > On Jul 19, 2019, at 3:20 AM, Fernando Bunn  wrote:
> >
> > Jim,
> > you're right, I was getting a false positive with -Q, sorry for the
> confusion.
> >
> > So it seems I'm having 2 issues on Xcode, right?
> > A - No rejection of illegal options (-Q)
> > B - "-q" with the correct queue name is not working.
> >
> > Here's what I'm doing for B:
> >
> > 1 - (lldb) thread info
> > thread #1: tid = 0xfc5f, 0x0001070418f4
> ThreadTest`ViewController.viewDidLoad(self=0x7f940610d270) at
> ViewController.swift:16:9, queue = 'com.apple.main-thread', stop reason =
> breakpoint 1.1
> >
> > 2 - (lldb) breakpoint set --file ViewController.swift --line 26 -q
> com.apple.main-thread
> > Breakpoint 2: where = ThreadTest`ThreadTest.ViewController.viewDidLoad()
> -> () + 942 at ViewController.swift:26:15, address = 0x000107041c0e
> >
> > 3 - (lldb) breakpoint list 2
> > 2: file = 'ViewController.swift', line = 26, exact_match = 0, locations
> = 1, resolved = 1, hit count = 0 Options: enabled queue name:
> "com.apple.main-thread"
> >   2.1: where = ThreadTest`ThreadTest.ViewController.viewDidLoad() -> ()
> + 942 at ViewController.swift:26:15, address = 0x000107041c0e,
> resolved, hit count = 0
> >
> > On #1 I just make sure the queue name is correct, com.apple.main-thread,
> then on #2 I set the breakpoint with "-q", and on #3 I make sure that the
> parameter was set correctly, and I do see the enabled queue name:
> "com.apple.main-thread" in there, but the breakpoint is never executed.
> >
> > But if I set  breakpoint set --file ViewController.swift --line 26,
> without -q, the breakpoint is executed normally.
> > And to check that the queue name is "com.apple.main-thread" when this
> breakpoint is executed I did the following:
> >
> > 1 - (lldb) breakpoint set --file ViewController.swift --line 26
> > Breakpoint 3: where = ThreadTest`ThreadTest.ViewController.viewDidLoad()
> -> () + 942 at ViewController.swift:26:15, address = 0x000104a01c0e
> > 2 - (lldb) c
> > Process 1242 resuming
> > 3 - (lldb) thread info
> > thread #1: tid = 0x11cd2, 0x000104a01c0e
> ThreadTest`ViewController.viewDidLoad(self=0x7fcb15d09d50) at
> ViewController.swift:26:15, queue = 'com.apple.main-thread', stop reason =
> breakpoint 3.1
> >
> > I can verify that on #3 the queue name is in fact com.apple.main-thread
> but if I add -q com.apple.main-thread, it doesn't work.
> >
> > At this point, I'm not sure what to do next, maybe file a radar with
> Apple?
> > Thanks for your help, I really appreciate it :)
> >
> > --
> > Fernando
> >
> >
> >
> > On Fri, Jul 19, 2019 at 1:27 AM Jim Ingham  wrote:
> > Fernando, I don't see quite what you do.  For me, -Q never sets the
> queue.  Rather, the current Xcode version of lldb seems to have a bug where
> it doesn't reject illegal options, so the -Q argument is silently
> discarded.  That would cause the breakpoint to "work" but it won't only
> stop on one queue. So I see:
> >
> >
> > (lldb) break set -f main.c -l 10 -q whatever
> > Breakpoint 1: where = SomeTool`main + 22 at main.c:13:3, address =
> 0x00010f66
> > (lldb) break list 1
> > 1: file = 'main.c', line = 10, exact_match = 0, locations = 1, resolved
> = 1, hit count = 0 Options: enabled queue name: "whatever"
> >   1.1: where = SomeTool`main + 22 at main.c:13:3, address =
> 0x00010f66, resolved, hit count = 0
> >
> > That's right, it got the queue name and should match against it.  But:
> >
> > (lldb) break set -f main.c -l 10 -Q whatever
> > Breakpoint 2: where = SomeTool`main + 22 at main.c:13:3, address =
> 0x00010f66
> > (lldb) break list 2
> > 2: file = 'main.c', line = 10, exact_match = 0, locations = 1, resolved
> = 1, hit count = 0
> >   2.1: where = SomeTool`main + 22 at main.c:13:3, address =
> 0x00010f66, resolved, hit count = 0
> >
> > That one didn't get a queue name at all.  So it will always stop, but
> OTOH that's not really what you wanted.
> >
> > It sounds like what is really going on is that the queue matching isn't
> working as you expected, so when you actually DID set a queue name - using
> the "-q" option, the breakpoint wasn't stopping, but when you didn't set a
> queue name (with the bogus -Q option) it did stop.  So there might be
> something going wrong with the queue name matching?
> >
> > Note, this bug doesn't exist in current llvm TOT.  If you try with that
> lldb:
> >
> > (lldb) break set -f foo.c -l 10 -Q foo
> > error: unknown or ambiguous option
> >
> > That's right, there is no -Q option...
> >
> > I'm surprised w