- User Since
- Aug 13 2019, 4:58 AM (96 w, 3 d)
Tue, Jun 15
Sat, Jun 12
Fri, Jun 11
Thu, Jun 10
I've looked into which bits of compiler-rt already work for x32 and it's actually a lot, yet despite that it should not be enabled: what gets built for builtins works, but various functions that should be defined are left out, and the sanitizers that work depend on libunwind, which does not even build. So, I think it's fine to just go ahead and commit this as it then, and we can fix and enable things later on. (I'm working on that btw, but it'll be a while before anything's ready to be submitted.)
Mon, Jun 7
Sun, Jun 6
Ah, problem found, I think: this breaks when ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=OFF, which I never explicitly set but had inherited as I was using a CMakeCache.txt generated when that was the default. As far as I know this is, for now, a supported configuration. The new pass manager was enabled by default by D95380 and one of the major differences listed there is "LCSSA and LoopSimplify are run before all loop passes"; it seems like this change may be relying on that. Should this perhaps be reverted until the problem can be fixed?
I'm seeing test failures now that this has been committed. These tests pass again after reverting this. (Tested on 21653600 directly and re-tested on 12f53e53, and tested the revert on top of the latter.) However, I have not found the same errors in the CI results, https://lab.llvm.org/buildbot/#/changes/22300 shows these tests as passing even in configurations that enable assertions. Is it possible that something in here, or something relied upon by something in here, is not fully deterministic and produces different results in different build configurations? I will try different build configurations to see if I can find one where the tests pass, and compare just what the two different builds do, but if you can spot a potential problem straightaway and suggest something to try that would be very helpful.
Sat, Jun 5
After adding a new test for the disassembly of these instructions, I found that I had not fully tested my previous version's attempt at disassembling: it only correctly handled the disassembly of addr32 maskmovdqu, not that of addr32 vmaskmovdqu. This version fixes it and adds tests for it. The instruction classes confuse me, so I may have missed a simpler way of achieving the same result.
Thu, Jun 3
Wed, Jun 2
Tue, Jun 1
Thanks. Accidentally pushed without updating the commit message, linking and closing manually.
Mon, May 31
Thu, May 27
Should I continue waiting for @saugustine to check the gdb part of this? If it takes too long to get that reviewed it might be better if I split this in two so that I can at least commit the non-gdb parts already.
Fri, May 21
May 16 2021
The switch to --no-x86_scrub_rip by default makes sense to me.
May 15 2021
Removed the shared object testing.
May 14 2021
I'm assuming you meant don't base the test on the old x86-64-plt.s, but the new is fine. Done now, and removed gotPltEntrySize.
This diff is identical to the previous diff, but hopefully a reupload will redo the CI.
May 12 2021
May 10 2021
May 9 2021
Added gnux32 to test.
May 6 2021
Apparently Phabricator detected the presence of "revert D100625" in my alternative D101851's description and marked that as reverting this one. Of course, as this hadn't been committed, it cannot have been reverted either. Could you confirm that things work for you now, @Abpostelnicu?
May 5 2021
May 4 2021
There is a risk of bitcode incompatibilities with this change, but we already have that the code we generate now is incompatible with GCC and results in crashes that way too, I don't think there's a perfect fix, I'd like it if we could merge this. I came up with roughly the same patch today, based on current sources, to fix bug #50198 before finding this one.
May 2 2021
It's bad enough that this warns for
May 1 2021
It wasn't just the alignment that was wrong, the section contains its own size as a field, which had an incorrect value as a result of the alignment.
Apr 29 2021
Apr 28 2021
Apr 27 2021
Apr 14 2021
Apr 12 2021
Apr 9 2021
Apr 8 2021
Ah, that looks at first glance like not a compiler-rt problem but a clang problem, it will need to be taught the correct target name for x32 as well. If I'm right, that should be easy to fix, I can take a look later today or tomorrow.
Apr 6 2021
I think x32 is not really supported by compiler-rt.
Does this change mean the various *_SUPPORTED_ARCH need updating to list x32 as supported too, or are those handled separately?
Apr 1 2021
Mar 31 2021
I have also updated the summary to provide a more complete explanation of the changes, and hope the revised summary will answer @MaskRay's questions.
Tests now updated differently, avoiding the need to explicitly list libx32 as an allowed libdir. In clang/test/Preprocessor/iwithprefix.c's case, for the purposes of the test, it is not necessary to look at what appears before /clang/. In the other tests, it is possible to capture the -resource-dir string and use that.
This updates the diff as described, plus includes test suite changes needed to make check-clang pass. The changes to clang/test/Driver/Inputs/basic_cross_linux_tree/usr are because we now correctly detect that a x86_64 GCC directory that does not include x32 files cannot be used to target x32.
Feel free to update the diff here with your suggested patch.
Mar 30 2021
If that were the reason, why are we not using the last GPLv2 version of config.guess, rather than the one that we happened to use back when we had an autoconf build system?