[llvm-branch-commits] [compiler-rt] release/19.x: [asan][cmake][test] Fix finding dynamic asan runtime lib (#100083) (PR #100322)
rorth wrote: I guess it's reasonably safe, though as patch author I may be biased. The `LD_LIBRARY_PATH*` part will only affect x86 and has been tested on both Solaris and Linux. The current `RPATH` handling is plain wrong, so no harm here. Maybe give it a couple of days soak time on `main` before backporting? https://github.com/llvm/llvm-project/pull/100322 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [compiler-rt] release/19.x: [asan][cmake][test] Fix finding dynamic asan runtime lib (#100083) (PR #100322)
rorth wrote: Yes: there have been no issues on `main` whatsoever, so it should be safe enough. https://github.com/llvm/llvm-project/pull/100322 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [compiler-rt] [sanitizer_common] Fix internal_*stat on Linux/sparc64 (PR #101236)
https://github.com/rorth milestoned https://github.com/llvm/llvm-project/pull/101236 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [compiler-rt] [sanitizer_common] Fix internal_*stat on Linux/sparc64 (PR #101236)
https://github.com/rorth created
https://github.com/llvm/llvm-project/pull/101236
Backport of fcd6bd5587cc376cd8f43b60d1c7d61fdfe0f535 and
16e9bb9cd7f50ae2ec7f29a80bc3b95f528bfdbf to `release/19.x` branch.
>From 7d97041c217bcb4b04cacb3a5d17285f8b241a88 Mon Sep 17 00:00:00 2001
From: Rainer Orth
Date: Tue, 30 Jul 2024 09:03:00 +0200
Subject: [PATCH 1/2] [sanitizer_common] Fix internal_*stat on Linux/sparc64
(#101012)
```
SanitizerCommon-Unit :: ./Sanitizer-sparcv9-Test/SanitizerCommon/FileOps
```
`FAIL`s on 64-bit Linux/sparc64:
```
projects/compiler-rt/lib/sanitizer_common/tests/./Sanitizer-sparcv9-Test
--gtest_filter=SanitizerCommon.FileOps
--
compiler-rt/lib/sanitizer_common/tests/sanitizer_libc_test.cpp:144: Failure
Expected equality of these values:
len1 + len2
Which is: 10
fsize
Which is: 1721875535
```
The issue is similar to the mips64 case: the Linux/sparc64 `*stat`
syscalls take a `struct kernel_stat64 *` arg. Also the syscalls actually
used differ.
This patch handles this, adopting the mips64 code to avoid too much
duplication.
Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
(cherry picked from commit fcd6bd5587cc376cd8f43b60d1c7d61fdfe0f535)
---
.../lib/sanitizer_common/sanitizer_linux.cpp | 41 +++
1 file changed, 34 insertions(+), 7 deletions(-)
diff --git a/compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
b/compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
index 76acf591871ab..09f58b7ced2e9 100644
--- a/compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
+++ b/compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
@@ -33,11 +33,15 @@
// For mips64, syscall(__NR_stat) fills the buffer in the 'struct kernel_stat'
// format. Struct kernel_stat is defined as 'struct stat' in asm/stat.h. To
// access stat from asm/stat.h, without conflicting with definition in
-// sys/stat.h, we use this trick.
-# if SANITIZER_MIPS64
+// sys/stat.h, we use this trick. sparc64 is similar, using
+// syscall(__NR_stat64) and struct kernel_stat64.
+# if SANITIZER_MIPS64 || SANITIZER_SPARC64
#include
#include
#define stat kernel_stat
+#if SANITIZER_SPARC64
+# define stat64 kernel_stat64
+#endif
#if SANITIZER_GO
# undef st_atime
# undef st_mtime
@@ -48,6 +52,7 @@
#endif
#include
#undef stat
+#undef stat64
# endif
# include
@@ -285,8 +290,7 @@ uptr internal_ftruncate(fd_t fd, uptr size) {
return res;
}
-#if (!SANITIZER_LINUX_USES_64BIT_SYSCALLS || SANITIZER_SPARC) && \
-SANITIZER_LINUX
+#if !SANITIZER_LINUX_USES_64BIT_SYSCALLS && SANITIZER_LINUX
static void stat64_to_stat(struct stat64 *in, struct stat *out) {
internal_memset(out, 0, sizeof(*out));
out->st_dev = in->st_dev;
@@ -327,7 +331,12 @@ static void statx_to_stat(struct statx *in, struct stat
*out) {
}
#endif
-#if SANITIZER_MIPS64
+#if SANITIZER_MIPS64 || SANITIZER_SPARC64
+# if SANITIZER_MIPS64
+typedef struct kernel_stat kstat_t;
+# else
+typedef struct kernel_stat64 kstat_t;
+# endif
// Undefine compatibility macros from
// so that they would not clash with the kernel_stat
// st_[a|m|c]time fields
@@ -345,7 +354,7 @@ static void statx_to_stat(struct statx *in, struct stat
*out) {
#undef st_mtime_nsec
#undef st_ctime_nsec
# endif
-static void kernel_stat_to_stat(struct kernel_stat *in, struct stat *out) {
+static void kernel_stat_to_stat(kstat_t *in, struct stat *out) {
internal_memset(out, 0, sizeof(*out));
out->st_dev = in->st_dev;
out->st_ino = in->st_ino;
@@ -391,6 +400,12 @@ uptr internal_stat(const char *path, void *buf) {
!SANITIZER_SPARC
return internal_syscall(SYSCALL(newfstatat), AT_FDCWD, (uptr)path, (uptr)buf,
0);
+# elif SANITIZER_SPARC64
+ kstat_t buf64;
+ int res = internal_syscall(SYSCALL(fstatat64), AT_FDCWD, (uptr)path,
+ (uptr)&buf64, 0);
+ kernel_stat_to_stat(&buf64, (struct stat *)buf);
+ return res;
# else
struct stat64 buf64;
int res = internal_syscall(SYSCALL(fstatat64), AT_FDCWD, (uptr)path,
@@ -423,6 +438,12 @@ uptr internal_lstat(const char *path, void *buf) {
!SANITIZER_SPARC
return internal_syscall(SYSCALL(newfstatat), AT_FDCWD, (uptr)path, (uptr)buf,
AT_SYMLINK_NOFOLLOW);
+# elif SANITIZER_SPARC64
+ kstat_t buf64;
+ int res = internal_syscall(SYSCALL(fstatat64), AT_FDCWD, (uptr)path,
+ (uptr)&buf64, AT_SYMLINK_NOFOLLOW);
+ kernel_stat_to_stat(&buf64, (struct stat *)buf);
+ return res;
# else
struct stat64 buf64;
int res = internal_syscall(SYSCALL(fstatat64), AT_FDCWD, (uptr)path,
@@ -442,10 +463,16 @@ uptr internal_fstat(fd_t fd, void *buf) {
#if SANITIZER_FREEBSD || SANITIZER_LINUX_USES_64BIT_SYSCALLS
# if SANITIZER_MIPS64
// For mips64, fstat syscall fills buffer in the format of kernel_stat
- st
[llvm-branch-commits] [compiler-rt] [sanitizer_common] Fix internal_*stat on Linux/sparc64 (PR #101236)
https://github.com/rorth edited https://github.com/llvm/llvm-project/pull/101236 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [compiler-rt] [sanitizer_common] Fix internal_*stat on Linux/sparc64 (PR #101236)
rorth wrote: I know, that's how I did it for the original PR. However, when it turned out 16e9bb9cd7f50ae2ec7f29a80bc3b95f528bfdbf was necessary too to unbreak the Solaris/sparcv9 build, I added a separate cherry pick just for that one. I guess I should just have closed the original PR and added a new cherry pick referring to both the base commit and the adjustment. https://github.com/llvm/llvm-project/pull/101236 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [compiler-rt] [sanitizer_common] Fix internal_*stat on Linux/sparc64 (PR #101236)
https://github.com/rorth closed https://github.com/llvm/llvm-project/pull/101236 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [compiler-rt] [sanitizer_common] Fix internal_*stat on Linux/sparc64 (PR #101236)
rorth wrote: This can now be closed: one part (PR #101012) has already been merged and the necessary rest is now PR #104916. https://github.com/llvm/llvm-project/pull/101236 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [compiler-rt] [sanitizer_common] Make sanitizer_linux.cpp kernel_stat* handling Lin… (PR #104916)
rorth wrote: The Solaris/sparcv9 build just completed successfully: no regressions relative to rc2. https://github.com/llvm/llvm-project/pull/104916 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/18.x: [Release] Don't build during test-release.sh Phase 3 install (#82001) (PR #82420)
rorth wrote: > @tstellar What do you think about merging this PR to the release branch? I thing this would be very useful: we already have two Issues filed for this problem, and `test-release.sh` is probably almost exclusively exercised during release testing/building. The risk should be limited: even if the patch is wrong, the builds will happen at full parallelism, no worse than before. https://github.com/llvm/llvm-project/pull/82420 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [compiler-rt] 9301cd5 - [sanitizer_common] Make sanitizer_linux.cpp kernel_stat* handling Linux-specific
Author: Rainer Orth Date: 2024-08-20T13:34:13+02:00 New Revision: 9301cd5b57c09214256edf19753e2e047a5b5f91 URL: https://github.com/llvm/llvm-project/commit/9301cd5b57c09214256edf19753e2e047a5b5f91 DIFF: https://github.com/llvm/llvm-project/commit/9301cd5b57c09214256edf19753e2e047a5b5f91.diff LOG: [sanitizer_common] Make sanitizer_linux.cpp kernel_stat* handling Linux-specific fcd6bd5587cc376cd8f43b60d1c7d61fdfe0f535 broke the Solaris/sparcv9 buildbot: ``` compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp:39:14: fatal error: 'asm/unistd.h' file not found 39 | #include | ^~ ``` That section should have been Linux-specific in the first place, which is what this patch does. Tested on sparcv9-sun-solaris2.11. (cherry picked from commit 16e9bb9cd7f50ae2ec7f29a80bc3b95f528bfdbf) Added: Modified: compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp Removed: diff --git a/compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp b/compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp index 8d375ffcd079c9..648df0c4e5a760 100644 --- a/compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp +++ b/compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp @@ -35,7 +35,7 @@ // access stat from asm/stat.h, without conflicting with definition in // sys/stat.h, we use this trick. sparc64 is similar, using // syscall(__NR_stat64) and struct kernel_stat64. -# if SANITIZER_MIPS64 || SANITIZER_SPARC64 +# if SANITIZER_LINUX && (SANITIZER_MIPS64 || SANITIZER_SPARC64) #include #include #define stat kernel_stat ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [compiler-rt] release/19.x: [builtins] Fix divtc3.c etc. compilation on Solaris/SPARC with gcc (#101662) (PR #101847)
rorth wrote: It's difficult: on one hand it fixes a Solaris/SPARC build failure. On the other, it's said to cause problems for an out-of-tree z/OS port. Unfortunately, the developers refuse to publish their code, so it's almost impossible to reason about that code. https://github.com/llvm/llvm-project/pull/101847 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [compiler-rt] [profile] Change __llvm_profile_counter_bias type to match llvm (PR #107362)
https://github.com/rorth created
https://github.com/llvm/llvm-project/pull/107362
As detailed in Issue #101667, two `profile` tests `FAIL` on 32-bit SPARC, both
Linux/sparc64 and Solaris/sparcv9 (where the tests work when enabled):
```
Profile-sparc :: ContinuousSyncMode/runtime-counter-relocation.c
Profile-sparc :: ContinuousSyncMode/set-file-object.c
```
The Solaris linker provides the crucial clue as to what's wrong:
```
ld: warning: symbol '__llvm_profile_counter_bias' has differing sizes:
(file runtime-counter-relocation-17ff25.o value=0x8; file
libclang_rt.profile-sparc.a(InstrProfilingFile.c.o) value=0x4);
runtime-counter-relocation-17ff25.o definition taken
```
In fact, the types in `llvm` and `compiler-rt` differ:
- `__llvm_profile_counter_bias`/`INSTR_PROF_PROFILE_COUNTER_BIAS_VAR` is
created in `llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp`
(`InstrLowerer::getCounterAddress`) as `int64_t`, while
`compiler-rt/lib/profile/InstrProfilingFile.c` uses `intptr_t`. While this
doesn't matter in the 64-bit case, the type sizes differ for 32-bit.
This patch changes the `compiler-rt` type to match `llvm`. At the same time,
the affected testcases are enabled on Solaris, too, where they now just `PASS`.
Tested on `sparc64-unknown-linux-gnu`, `sparcv9-sun-solaris2.11`,
`x86_64-pc-linux-gnu`, and `amd64-pc-solaris2.11.
This is a backport of PR #102747, adjusted for the lack of
`__llvm_profile_bitmap_bias` on the `release/19.x` branch.
>From 086147ec9d3428b6abe137f1d7ac7aa17aa8a715 Mon Sep 17 00:00:00 2001
From: Rainer Orth
Date: Thu, 5 Sep 2024 09:51:08 +0200
Subject: [PATCH] [profile] Change __llvm_profile_counter_bias type to match
llvm
As detailed in Issue #101667, two `profile` tests `FAIL` on 32-bit
SPARC, both Linux/sparc64 and Solaris/sparcv9 (where the tests work when
enabled):
```
Profile-sparc :: ContinuousSyncMode/runtime-counter-relocation.c
Profile-sparc :: ContinuousSyncMode/set-file-object.c
```
The Solaris linker provides the crucial clue as to what's wrong:
```
ld: warning: symbol '__llvm_profile_counter_bias' has differing sizes:
(file runtime-counter-relocation-17ff25.o value=0x8; file
libclang_rt.profile-sparc.a(InstrProfilingFile.c.o) value=0x4);
runtime-counter-relocation-17ff25.o definition taken
```
In fact, the types in `llvm` and `compiler-rt` differ:
- `__llvm_profile_counter_bias`/`INSTR_PROF_PROFILE_COUNTER_BIAS_VAR` is
created in `llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp`
(`InstrLowerer::getCounterAddress`) as `int64_t`, while
`compiler-rt/lib/profile/InstrProfilingFile.c` uses `intptr_t`. While
this doesn't matter in the 64-bit case, the type sizes differ for
32-bit.
This patch changes the `compiler-rt` type to match `llvm`. At the same
time, the affected testcases are enabled on Solaris, too, where they now
just `PASS`.
Tested on `sparc64-unknown-linux-gnu`, `sparcv9-sun-solaris2.11`,
`x86_64-pc-linux-gnu`, and `amd64-pc-solaris2.11.
This is a backport of PR #102747, adjusted for the lack of
`__llvm_profile_bitmap_bias` on the `release/19.x` branch.
---
compiler-rt/lib/profile/InstrProfilingFile.c| 6 +++---
compiler-rt/lib/profile/InstrProfilingPlatformFuchsia.c | 2 +-
.../profile/ContinuousSyncMode/runtime-counter-relocation.c | 2 +-
.../test/profile/ContinuousSyncMode/set-file-object.c | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/compiler-rt/lib/profile/InstrProfilingFile.c
b/compiler-rt/lib/profile/InstrProfilingFile.c
index 1c58584d2d4f73..3bb2ae068305c9 100644
--- a/compiler-rt/lib/profile/InstrProfilingFile.c
+++ b/compiler-rt/lib/profile/InstrProfilingFile.c
@@ -198,12 +198,12 @@ static int mmapForContinuousMode(uint64_t
CurrentFileOffset, FILE *File) {
#define INSTR_PROF_PROFILE_COUNTER_BIAS_DEFAULT_VAR
\
INSTR_PROF_CONCAT(INSTR_PROF_PROFILE_COUNTER_BIAS_VAR, _default)
-COMPILER_RT_VISIBILITY intptr_t INSTR_PROF_PROFILE_COUNTER_BIAS_DEFAULT_VAR =
0;
+COMPILER_RT_VISIBILITY int64_t INSTR_PROF_PROFILE_COUNTER_BIAS_DEFAULT_VAR = 0;
/* This variable is a weak external reference which could be used to detect
* whether or not the compiler defined this symbol. */
#if defined(_MSC_VER)
-COMPILER_RT_VISIBILITY extern intptr_t INSTR_PROF_PROFILE_COUNTER_BIAS_VAR;
+COMPILER_RT_VISIBILITY extern int64_t INSTR_PROF_PROFILE_COUNTER_BIAS_VAR;
#if defined(_M_IX86) || defined(__i386__)
#define WIN_SYM_PREFIX "_"
#else
@@ -214,7 +214,7 @@ COMPILER_RT_VISIBILITY extern intptr_t
INSTR_PROF_PROFILE_COUNTER_BIAS_VAR;
INSTR_PROF_PROFILE_COUNTER_BIAS_VAR) "=" WIN_SYM_PREFIX
\
INSTR_PROF_QUOTE(INSTR_PROF_PROFILE_COUNTER_BIAS_DEFAULT_VAR))
#else
-COMPILER_RT_VISIBILITY extern intptr_t INSTR_PROF_PROFILE_COUNTER_BIAS_VAR
+COMPILER_RT_VISIBILITY extern int64_t INSTR_PROF_PROFILE_COUNTER_BIAS_VAR
__attribute__((weak, alias(INSTR_PROF_QUOTE(
[llvm-branch-commits] [compiler-rt] [profile] Change __llvm_profile_counter_bias type to match llvm (PR #107362)
https://github.com/rorth milestoned https://github.com/llvm/llvm-project/pull/107362 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [compiler-rt] [profile] Change __llvm_profile_counter_bias type to match llvm (PR #107362)
https://github.com/rorth edited https://github.com/llvm/llvm-project/pull/107362 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [compiler-rt] [profile] Change __llvm_profile_counter_bias type to match llvm (PR #107362)
rorth wrote: > Hi, since we are wrapping up LLVM 19.1.0 we are very strict with the fixes we > pick at this point. Can you please respond to the following questions to help > me understand if this has to be included in the final release or not. I guess it's best for @petrhosek to make the final assessment. That said... > Is this PR a fix for a regression or a critical issue? ... it's not a regression but a long(er)-standing bug. Critical? Probably not. > What is the risk of accepting this into the release branch? > > What is the risk of NOT accepting this into the release branch? Although this has been on `main` for a couple of days now without complaint, I'd say it's safer to delay to a later 19.x.0 release at this point. https://github.com/llvm/llvm-project/pull/107362 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++] Make benchmarks dry-run by default on the release branch (PR #126441)
https://github.com/rorth milestoned https://github.com/llvm/llvm-project/pull/126441 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
