In D67583#1678505, @labath wrote:

This will work for the python-in-lldb case. However, the idea is lldb can also be used as python package, from any python application (by just typing import lldb). For that to work, we need to install lldb python stuff to a location that will be searched for by python in its default configuration.

I do not believe this to be the right approach. Unconditionally installing Python modules to the wrong directory is a bug, not a feature. It should be fixed (as I proposed in D67890), not made more prominent by making everything hinge on it.

Ping. This is a really silly issue, and one that could be fixed trivially, so it'd be really nice to actually fix it.

Test added. Thanks for the suggestion!

Nevermind that long report, it actually turned out to be a bug in NetBSD kernel that resulted in the thread not being resumed.

So I've made some progress on this. However, I'm stuck and I'd use some help going forward.

The problem is to complex too be implemented in smaller blocks. I'm going to close this in favor of a single unified patch in D64647.

But in that case, we should aim for consistency, i.e. remove the matching option from LLVM.

In D67585#1670422, @beanz wrote:

In D67585#1670420, @mgorny wrote:

Sure but I want to build-test practically everything else. I wouldn't mind if this didn't basically kill my test system by resource exhaustion

You can use the ‘LLVM_DISTRIBUTION_COMPONENTS’ option to create a build test target that includes the things you care to test.

Also note that I'm leaving it enabled by default, so only people explicitly opting out would not be testing it.

Sure but I want to build-test practically everything else. I wouldn't mind if this didn't basically kill my test system by resource exhaustion.

Thanks. Could you also ack the backport in https://bugs.llvm.org/show_bug.cgi?id=43281?

Reping.

In D63672#1659973, @dblaikie wrote:

In D63672#1657198, @mgorny wrote:

In D63672#1657183, @mgorny wrote:

Ok, I have an idea of using --test-arg but it would require the args to be passed before the filename. I'll post a patch.

Actually, I won't because I'm hitting some memory corruption in TestArgs and I don't really have time or motivation to fight it. Please fix your code.

Could you be more specific? I've tried running both tests under valgrind and haven't encountered any reported errors there.

Thanks. It seems to fix the test I used to bisect this. It will take some time before buildbot confirms this but I'm going to presume it's good now. If it fails more, I'll ping you.

In D63672#1657183, @mgorny wrote:

Ok, I have an idea of using --test-arg but it would require the args to be passed before the filename. I'll post a patch.

Ok, I have an idea of using --test-arg but it would require the args to be passed before the filename. I'll post a patch.

This broke NetBSD buildbots:
http://lab.llvm.org:8011/builders/netbsd-amd64/builds/22010/steps/run%20unit%20tests/logs/FAIL%3A%20LLVM%3A%3Aremove-funcs.ll
http://lab.llvm.org:8011/builders/netbsd-amd64/builds/22010/steps/run%20unit%20tests/logs/FAIL%3A%20LLVM%3A%3Aremove-global-vars.ll

In D62868#1650892, @ldionne wrote:

Quick update for watchers:

The bug mentioned by Peter has been fixed now, but I'm looking into other link errors when using GCC (because there's more).

Unless I'm mistaken, this is fixed by replacing std::call_once with llvm::call_once. I'll complete testing and commit it later today.

This broke NetBSD buildbot: http://lab.llvm.org:8011/builders/netbsd-amd64/builds/21974

Ping.

As I've noted on D64740, the code in breakpad is identical (except for ordering and whitespace changes) to our initial code. All code differences between us and breakpad are our local changes. Therefore, I think we can change the license in place. If you really insist, I can reorder the functions match ordering in breakpad, and do some whitespace changes ;-).

@sylvestre.ledru, I just went through breakpad code, comparing it with the initial code imported to clang. After reordering and aligning whitespace, the code is identical. This means that 1) the tests are failing because of regressions reintroduced by porting breakpad code, and 2) we can just change the license header because all differences in code are of our own making. Therefore, I propose that we go forward with D66390 instead of putting more time into regressing code just to fix it again.

Do you want me to try to take a look at the problems?

Actually, I think the license change can be submitted separately, so I'll do just that.

Any chance to move this forward? I've just noticed we're missing this one license, and fixing it would render LLVM non-free in Gentoo (read: cause a massive shitstorm for some of our users). I just wanted to do a similar port and found this while looking for earlier work.

This looks like a correct approach to me.

@jfb, could you please remove your red flag now? ;-)

In D64666#1613057, @ziangwan wrote:

The warning is actually correct here. This implicit integral to float conversion loses precision. Is it the intended behavior of the code? If so, we can simply add an explicit type cast to silence the warning.

This change seems to have broken libc++ tests when run with trunk clang:
http://lab.llvm.org:8011/builders/netbsd-amd64/builds/21221/steps/run%20unit%20tests/logs/FAIL%3A%20libc%2B%2B%3A%3Aeval.pass.cpp
and more in http://lab.llvm.org:8011/builders/netbsd-amd64/builds/21221

This change broke NetBSD buildbot:
http://lab.llvm.org:8011/builders/netbsd-amd64/builds/21240/steps/ninja%20build%20local/logs/stdio

WFM.

Not sure if we're taking about the same thing. I meant the status in resume actions. I think it'd be logical if 'no action' meant 'resume in same state as prior to stopping the process', and explicit eStateS* meant 'keep this thread stopped after resuming'.

It seems that the patch is wrong with the current logic, and this is somehow blurry because of Linux implementation limitations. FWIU, eStateSuspended will never happen and instead we should keep threads without explicit action suspsended. It's unclear yet whether this is desirable long-term, or if we should change the logic to explicitly indicate state for each thread.

In D65156#1608751, @jdenny wrote:

After debugging more on my system, it seems that not in front of a %{lit} causes lit's internal shell to use an external env instead of the internal env. Fine for ubuntu. Not fine for windows. Will post more later.

Hmm, I suspect the problem here mostly affects people running the test suite via CMake rule rather than directly, correct? So maybe it would be more portable to clean the env via ${CMAKE_PROGRAM} -E env ....

FTR, the failure fixed by this is: http://lab.llvm.org:8011/builders/netbsd-amd64/builds/21195/steps/run%20unit%20tests/logs/FAIL%3A%20lldb-Suite%3A%3ATestVSCode_launch.py

Are you talking about this *specific* change or the original change that added env usage?

In D65334#1602696, @jdenny wrote:

In D65334#1602675, @mgorny wrote:

We are using it to force verbose output on buildbot ;-).

Good to know. By the way, you'd get roughly the same output with FILECHECK_OPTS=-dump-input=fail, which is not deprecated. Adding -v or -vv will provide much more info.

We are using it to force verbose output on buildbot ;-). But setting to an empty value should be very uncommon. The uses I've been able to grep in LLVM all set it to 1.

This change broke NetBSD buildbots, e.g.: http://lab.llvm.org:8011/builders/netbsd-amd64/builds/21152/steps/run%20unit%20tests/logs/FAIL%3A%20lit%3A%3A%20googletest-upstream-format.py

Two more apparent XPASS-es.