On Fri, May 02, 2025 at 12:30:52PM +0200, Florian Weimer wrote:
> The termio structure will be removed from glibc 2.42. It has
> been deprecated since the late 80s/early 90s.
>
> Cherry-picked from LLVM commit 59978b21ad9c65276ee8e14f26759691b8a65763
> ("[sanitizer_common] Remove interceptors for
The termio structure will be removed from glibc 2.42. It has
been deprecated since the late 80s/early 90s.
Cherry-picked from LLVM commit 59978b21ad9c65276ee8e14f26759691b8a65763
("[sanitizer_common] Remove interceptors for deprecated struct termio
(#137403)").
Co-Authored-By: Tom Stellard
Sign
On 11/22/24 5:44 PM, Jakub Jelinek wrote:
Hi!
We aren't the master repository for the sanitizers and clearly upstream
introduces various extensions in the code.
All we care about is whether it builds and works fine with GCC, so
-pedantic flag is of no use to us, only maybe to upstream if they
Hi!
We aren't the master repository for the sanitizers and clearly upstream
introduces various extensions in the code.
All we care about is whether it builds and works fine with GCC, so
-pedantic flag is of no use to us, only maybe to upstream if they
cared about it (which they clearly don't).
Th
On Thu, Nov 21, 2024 at 05:21:27PM -0800, Andrew Pinski wrote:
> While compiling libsanitizer for aarch64-linux-gnu, I noticed the new warning:
> ```
> ../../../../libsanitizer/asan/asan_interceptors.cpp: In function ‘char*
> ___interceptor_strcpy(char*, const char*)’:
> ../../../../libsanitizer/a
While compiling libsanitizer for aarch64-linux-gnu, I noticed the new warning:
```
../../../../libsanitizer/asan/asan_interceptors.cpp: In function ‘char*
___interceptor_strcpy(char*, const char*)’:
../../../../libsanitizer/asan/asan_interceptors.cpp:554:6: warning: ‘if
constexpr’ only available
Jakub Jelinek writes:
> Hi!
>
> When gcc is built with -mbranch-protection=standard, running sanitized
> programs doesn't work properly on bti enabled kernels.
>
> This has been fixed upstream with
> https://github.com/llvm/llvm-project/pull/84061
>
> The following patch cherry picks that from ups
Hi!
When gcc is built with -mbranch-protection=standard, running sanitized
programs doesn't work properly on bti enabled kernels.
This has been fixed upstream with
https://github.com/llvm/llvm-project/pull/84061
The following patch cherry picks that from upstream, ok for trunk/14.3?
For trunk w
Upstream commit
https://github.com/llvm/llvm-project/commit/26800a2c7e7996dc773b4e990dd5cca41c45e1a9
of LLVM added a #undef _TIME_BITS in
libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp to
fix the build on 32-bit Linux platforms that have enabled 64-bit
time_t using _TIME_BITS=64.
On 4/4/24 14:22, Jakub Jelinek wrote:
> On Thu, Apr 04, 2024 at 02:19:08PM +0200, Andreas Krebbel wrote:
>> On 4/4/24 13:38, Ilya Leoshkevich wrote:
>>> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>>>
>>>
>>> libsanitizer/ChangeLog:
>>>
>>> * sanitizer_common/sanitizer_lin
On Thu, Apr 04, 2024 at 02:19:08PM +0200, Andreas Krebbel wrote:
> On 4/4/24 13:38, Ilya Leoshkevich wrote:
> > Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
> >
> >
> > libsanitizer/ChangeLog:
> >
> > * sanitizer_common/sanitizer_linux_s390.cpp (AvoidCVE_2016_2143):
> >
On 4/4/24 13:38, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
> libsanitizer/ChangeLog:
>
> * sanitizer_common/sanitizer_linux_s390.cpp (AvoidCVE_2016_2143):
> Do not mention MSan and DFSan, which are not supported by GCC.
Ok, Thank
Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
libsanitizer/ChangeLog:
* sanitizer_common/sanitizer_linux_s390.cpp (AvoidCVE_2016_2143):
Do not mention MSan and DFSan, which are not supported by GCC.
---
libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp |
Hi Jakub,
> On Fri, Feb 16, 2024 at 01:32:04PM +0100, Rainer Orth wrote:
>> c-c++-common/asan/swapcontext-test-1.c FAILs on Solaris/SPARC:
>>
>> FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 execution test
>> FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 execution test
>> FAIL: c-c++-
On Fri, Feb 16, 2024 at 01:32:04PM +0100, Rainer Orth wrote:
> c-c++-common/asan/swapcontext-test-1.c FAILs on Solaris/SPARC:
>
> FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 execution test
> FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 execution test
> FAIL: c-c++-common/asan/swapco
c-c++-common/asan/swapcontext-test-1.c FAILs on Solaris/SPARC:
FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 execution test
FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 execution test
FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 execution test
FAIL: c-c++-common/asan/swapcontex
Thanks for quick reply!
If it's an inappropriate patch for GCC, should I try to send it to Yocto then?
Alibek.
On Tue, Feb 6, 2024 at 8:53 AM Alibek Omarov wrote:
>
> Some libtool versions require --tag to be set and won't run compiler
> without it, throwing an `unable to infer tagged configuration` error.
>
> I'm not sure whether it's a good idea to tag assembly files as a C source,
> but it helps to avoi
Some libtool versions require --tag to be set and won't run compiler
without it, throwing an `unable to infer tagged configuration` error.
I'm not sure whether it's a good idea to tag assembly files as a C source,
but it helps to avoid the issue.
Signed-off-by: Alibek Omarov
---
libsanitizer/a
> -Original Message-
> From: Andrew Pinski
> Sent: Monday, January 29, 2024 9:55 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; ja...@redhat.com;
> do...@redhat.com; k...@google.com; dvyu...@google.com
> Subject: Re: [PATCH][libsanitizer]: Sync fixes
On Mon, Jan 29, 2024 at 7:04 AM Tamar Christina wrote:
>
> Hi All,
>
> This cherry-picks and squashes the differences between commits
>
> d3e5c20ab846303874a2a25e5877c72271fc798b..76e1e45922e6709392fb82aac44bebe3dbc2ea63
> from LLVM upstream from compiler-rt/lib/hwasan/ to GCC on the changes relev
On Mon, Jan 29, 2024 at 03:03:46PM +, Tamar Christina wrote:
> Hi All,
>
> This cherry-picks and squashes the differences between commits
>
> d3e5c20ab846303874a2a25e5877c72271fc798b..76e1e45922e6709392fb82aac44bebe3dbc2ea63
> from LLVM upstream from compiler-rt/lib/hwasan/ to GCC on the chan
Hi All,
This cherry-picks and squashes the differences between commits
d3e5c20ab846303874a2a25e5877c72271fc798b..76e1e45922e6709392fb82aac44bebe3dbc2ea63
from LLVM upstream from compiler-rt/lib/hwasan/ to GCC on the changes relevant
for GCC.
This is required to fix the linked PR.
As mentioned i
On Wed, Jan 17, 2024 at 09:17:09AM +0100, Daniel Cederman wrote:
> On 2024-01-16 15:44, Jakub Jelinek wrote:
> > On Tue, Jan 16, 2024 at 03:11:39PM +0100, Daniel Cederman wrote:
> > > When GCC is configured with --enable-target-optspace the compiler
> > > generates
> > > a memcpy call in the Symbo
On 2024-01-16 15:44, Jakub Jelinek wrote:
On Tue, Jan 16, 2024 at 03:11:39PM +0100, Daniel Cederman wrote:
When GCC is configured with --enable-target-optspace the compiler generates
a memcpy call in the Symbolizer constructor in sanitizer_symbolizer.cpp
when compiling for SPARC V8. Add HAVE_AS_
On Tue, Jan 16, 2024 at 03:11:39PM +0100, Daniel Cederman wrote:
> When GCC is configured with --enable-target-optspace the compiler generates
> a memcpy call in the Symbolizer constructor in sanitizer_symbolizer.cpp
> when compiling for SPARC V8. Add HAVE_AS_SYM_ASSIGN to replace it with a
> call
When GCC is configured with --enable-target-optspace the compiler generates
a memcpy call in the Symbolizer constructor in sanitizer_symbolizer.cpp
when compiling for SPARC V8. Add HAVE_AS_SYM_ASSIGN to replace it with a
call to __sanitizer_internal_memcpy.
libsanitizer/ChangeLog:
* sanit
On 1/2/24 06:56, Andreas Schwab wrote:
All new (tsan) tests are working as expected.
* configure.tgt (riscv64-*-linux*): Enable LSan and TSan.
OK
Jeff
All new (tsan) tests are working as expected.
* configure.tgt (riscv64-*-linux*): Enable LSan and TSan.
---
libsanitizer/configure.tgt | 5 +
1 file changed, 5 insertions(+)
diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index d24566a2343..38fc7001ff7 100644
---
On Tue, Nov 28, 2023 at 02:16:11PM +0100, Rainer Orth wrote:
> Hi Jakub,
>
> >>> But will they accept a patch to check a macro never set anywhere in and
> >>> irrelevant to LLVM? That's why I kept all in one patch, to be GCC-local.
> >>
> >> I meant the patch would be gcc local.
> >> But, for lat
Hi Jakub,
>>> But will they accept a patch to check a macro never set anywhere in and
>>> irrelevant to LLVM? That's why I kept all in one patch, to be GCC-local.
>>
>> I meant the patch would be gcc local.
>> But, for later we need only the changes to the imported files be in one
>> commit, not
Hi Jakub,
>> But will they accept a patch to check a macro never set anywhere in and
>> irrelevant to LLVM? That's why I kept all in one patch, to be GCC-local.
>
> I meant the patch would be gcc local.
> But, for later we need only the changes to the imported files be in one
> commit, not others
On Mon, Nov 27, 2023 at 02:20:25PM +0100, Rainer Orth wrote:
> Hi Jakub,
>
> >> 2023-11-23 Rainer Orth
> >>
> >>libsanitizer:
> >>PR libsanitizer/112563
> >>* configure.ac (libsanitizer_cv_as_sym_assign): Check for
> >>assembler symbol assignment support.
> >>* configure, c
Hi Jakub,
>> 2023-11-23 Rainer Orth
>>
>> libsanitizer:
>> PR libsanitizer/112563
>> * configure.ac (libsanitizer_cv_as_sym_assign): Check for
>> assembler symbol assignment support.
>> * configure, config.h.in: Regenerate.
>> * sanitizer_common/sanitizer_redefine
On Mon, Nov 27, 2023 at 01:56:46PM +0100, Rainer Orth wrote:
> The recent libsanitizer import broke the build on Solaris/SPARC with the
> native as:
>
> /usr/ccs/bin/as: ".libs/sanitizer_errno.s", line 4247: error: symbol
> "__sanitizer_internal_memset" is used but not defined
> /usr/ccs/bin/as:
The recent libsanitizer import broke the build on Solaris/SPARC with the
native as:
/usr/ccs/bin/as: ".libs/sanitizer_errno.s", line 4247: error: symbol
"__sanitizer_internal_memset" is used but not defined
/usr/ccs/bin/as: ".libs/sanitizer_errno.s", line 4247: error: symbol
"__sanitizer_interna
> ${target} in there shouldn't be what user specified, but what config.sub
> canonicalized it to.
> And
> ./config.sub x86_64-linux; ./config.sub loongarch64-linux
> x86_64-pc-linux-gnu
> loongarch64-unknown-linux-gnu
> so I really don't see why you want to change it.
OK, I see. Thanks.
Yujie
On Thu, Nov 16, 2023 at 04:01:13PM +0800, Yang Yujie wrote:
> libsanitizer/ChangeLog:
>
> * configure.tgt: allow loongarch64-linux-*.
${target} in there shouldn't be what user specified, but what config.sub
canonicalized it to.
And
./config.sub x86_64-linux; ./config.sub loongarch64-linux
x
libsanitizer/ChangeLog:
* configure.tgt: allow loongarch64-linux-*.
---
libsanitizer/configure.tgt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index d24566a2343..5af524cb271 100644
--- a/libsanitizer/configure
On Mon, Aug 07, 2023 at 11:13:10AM +0200, Rainer Orth wrote:
> As detailed in LLVM Issue #57624
> (https://github.com/llvm/llvm-project/issues/57624), a patch to
> sanitizer_internal_defs.h broke SPARC stacktraces in the sanitizers.
> The issue has now been fixed upstream (https://reviews.llvm.org/
As detailed in LLVM Issue #57624
(https://github.com/llvm/llvm-project/issues/57624), a patch to
sanitizer_internal_defs.h broke SPARC stacktraces in the sanitizers.
The issue has now been fixed upstream (https://reviews.llvm.org/D156504)
and I'd like to cherry-pick that patch.
Bootstrapped withou
On Thu, Apr 27, 2023 at 12:03 AM Martin Liška wrote:
>
> On 4/27/23 04:32, H.J. Lu via Gcc-patches wrote:
> > cherry-pick:
>
> Can you please wait a few days before it? I'm going to merge again
> in the near future after https://reviews.llvm.org/D144073 got handled.
Sure.
> Martin
>
> >
> > 0555
On 4/27/23 04:32, H.J. Lu via Gcc-patches wrote:
> cherry-pick:
Can you please wait a few days before it? I'm going to merge again
in the near future after https://reviews.llvm.org/D144073 got handled.
Martin
>
> 05551c658269 [sanitizer] Correct alignment of x32 __sanitizer_siginfo
>
> *
cherry-pick:
05551c658269 [sanitizer] Correct alignment of x32 __sanitizer_siginfo
* sanitizer_common/sanitizer_platform_limits_posix.h
(__sanitizer_siginfo_pad): Use u64 to align x32
__sanitizer_siginfo to 8 bytes.
---
.../sanitizer_common/sanitizer_platform_limits_posix
On Tue, Jan 31, 2023 at 02:39:54PM -0800, H.J. Lu wrote:
> cherry-pick:
>
> 742bcbf685bc compiler-rt/lib: Add .Linterceptor_sigsetjmp
>
> PR sanitizer/108106
> * hwasan/hwasan_setjmp_x86_64.S (__interceptor_setjmp): Jump
> to .Linterceptor_sigsetjmp instead of __interceptor_sigs
cherry-pick:
742bcbf685bc compiler-rt/lib: Add .Linterceptor_sigsetjmp
PR sanitizer/108106
* hwasan/hwasan_setjmp_x86_64.S (__interceptor_setjmp): Jump
to .Linterceptor_sigsetjmp instead of __interceptor_sigsetjmp.
(__interceptor_sigsetjmp): Add a local alias,
On Fri, Dec 16, 2022 at 01:31:32PM -0800, H.J. Lu via Gcc-patches wrote:
> Add an internal alias to __interceptor_sigsetjmp to avoid R_X86_64_PC32
> relocation for "jmp __interceptor_sigsetjmp" with old assemblers.
I think the patch is ok, but because libsanitizer is just downstream
from sanitizer
On Tue, Jan 17, 2023 at 9:58 AM Rainer Orth
wrote:
>
> When using GNU ld on Solaris, a large number of asan tests SEGV, while
> Solaris ld is fine. This happens inside the __tls_get_addr interceptor,
> which is highly glibc-specific. Therefore this patch disables that
> interceptor.
>
> Posted
When using GNU ld on Solaris, a large number of asan tests SEGV, while
Solaris ld is fine. This happens inside the __tls_get_addr interceptor,
which is highly glibc-specific. Therefore this patch disables that
interceptor.
Posted upstream at https://reviews.llvm.org/D141385.
Tested on i386-pc-s
Hans-Peter Nilsson 于2023年1月11日周三 08:53写道：
>
> On Fri, 6 Jan 2023, YunQiang Su wrote:
>
> > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 is always used for mips
> > when build libsanitizer in LLVM. Thus
> >FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 176 : 160, 216);
> > instead of
> >FIRST_32
On Fri, 6 Jan 2023, YunQiang Su wrote:
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 is always used for mips
> when build libsanitizer in LLVM. Thus
>FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 176 : 160, 216);
> instead of
>FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216);
> in
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 is always used for mips
when build libsanitizer in LLVM. Thus
FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 176 : 160, 216);
instead of
FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216);
in sanitizer_platform_limits_posix.h.
To keep sync wit
Add an internal alias to __interceptor_sigsetjmp to avoid R_X86_64_PC32
relocation for "jmp __interceptor_sigsetjmp" with old assemblers.
PR sanitizer/108106
* hwasan/hwasan_setjmp_x86_64.S (__interceptor_sigsetjmp): Add
an internal alias, __interceptor_sigsetjmp_internal.
On Tue, Oct 18, 2022 at 11:39:25AM +0200, Florian Weimer via Gcc-patches wrote:
> libsanitizer/
>
> * configure.ac (check for necessary platform features):
I'd use (sanitizer_supported) or (SANITIZER_SUPPORTED) above instead,
that is what is what is being determined by the test.
> In
libsanitizer/
* configure.ac (check for necessary platform features):
Include for syscall prototype.
* configure: Regenerate.
---
libsanitizer/configure| 5 +++--
libsanitizer/configure.ac | 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/libsan
OK!
Thanks!
在 2022/8/31 下午1:54, Xi Ruoyao 写道:
The LoongArch support for libubsan and libasan has been added in:
- https://reviews.llvm.org/D129371
- https://reviews.llvm.org/D129418
and we've merged them in r13-2269. It's time to enable them.
No unexpected failures in GCC asan.exp and ubsan
The LoongArch support for libubsan and libasan has been added in:
- https://reviews.llvm.org/D129371
- https://reviews.llvm.org/D129418
and we've merged them in r13-2269. It's time to enable them.
No unexpected failures in GCC asan.exp and ubsan.exp tests.
libsanitizer/ChangeLog:
* co
On 7/29/22 08:38, Dimitrije Milosevic wrote:
> Thanks Martin! I'm sending out the output from git format-patch as an
> attachment to this email.
You're welcome, pushed as r13-1909-g1efeaf99bd8bdf.
Cheers,
Martin
t: Re: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from
upstream
On 7/28/22 15:43, Dimitrije Milosevic wrote:
> |Gentle ping, requiring someone to push the change. :)|
Sure, I can do that, but please attach output of (git format-patch) as an
attachment
to an email. The current e
On 7/28/22 15:43, Dimitrije Milosevic wrote:
> |Gentle ping, requiring someone to push the change. :)|
Sure, I can do that, but please attach output of (git format-patch) as an
attachment
to an email. The current email has a weird format I can directly apply with git
am.
Cheers,
Martin
Gentle ping, requiring someone to push the change. :)
From: Dimitrije Milosevic
Sent: Monday, July 25, 2022 8:55 AM
To: gcc-patches@gcc.gnu.org
Cc: Djordje Todorovic ; xry...@xry111.site
Subject: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from
upstream
Dimitrije Milosevic writes:
>> Do you know someone very familiar with MIPS and GCC and capable as a
>> port maintainer? An active MIPS port maintainer will make the situation
>> better.
> Sadly, no. I agree it would make things easier.
Yeah, I agree that's what we need. I stepped down from bein
ic ;
gcc-patches@gcc.gnu.org
Cc: Djordje Todorovic ; richard.sandif...@arm.com
Subject: Re: PING: [PATCH] libsanitizer: Cherry-pick
2bfb0fcb51510f22723c8cdfefe from upstream
On Wed, 2022-07-27 at 06:41 +, Dimitrije Milosevic wrote:
> Gentle ping, requiring someone to push this change, as I
On Wed, 2022-07-27 at 06:41 +, Dimitrije Milosevic wrote:
> Gentle ping, requiring someone to push this change, as I do not have
> commit access. :)
Do you know someone very familiar with MIPS and GCC and capable as a
port maintainer? An active MIPS port maintainer will make the situation
bet
Gentle ping, requiring someone to push this change, as I do not have commit
access. :)
From: Dimitrije Milosevic
Sent: Monday, July 25, 2022 8:55 AM
To: gcc-patches@gcc.gnu.org
Cc: Djordje Todorovic ; xry...@xry111.site
Subject: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe
Gentle ping :).
On Thu, 2022-06-30 at 12:22 +0800, Xi Ruoyao wrote:
> In libsanitizer code, the size of some GNU libc data structure
> (notably,
> struct stat) is hard coded. These sizes may trigger a static assert
> buidling against another libc.
>
> Just make non-GNU libc targets UNSUPPORTED n
LGTM. Requiring permission to push.
> +const unsigned struct_kernel_stat_sz =
> + SANITIZER_ANDROID
> + ? FIRST_32_SECOND_64(104, 128)
> + : FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216);
These values matches sizeof(struct stat) on gcc230, so should be
correct:
xr
2bfb0fcb51510f22723c8cdfefe [Sanitizer][MIPS] Fix stat struct size for the O32
ABI.
Signed-off-by: Dimitrije Milosevic .
---
.../sanitizer_common/sanitizer_platform_limits_posix.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libsanitizer/sanitizer_common/saniti
On Fri, Jul 22, 2022 at 11:29 AM Rainer Orth
wrote:
>
> The libsanitizer build has been broken on Solaris 11.3 by the latest
> import. An upstream patch to fix this has now been committed:
>
> [sanitizer_common] Support Solaris < 11.4 in GetStaticTlsBoundary
> https://reviews.llvm
The libsanitizer build has been broken on Solaris 11.3 by the latest
import. An upstream patch to fix this has now been committed:
[sanitizer_common] Support Solaris < 11.4 in GetStaticTlsBoundary
https://reviews.llvm.org/D120059
I'd like to cherry-pick it into libsanitizer, too.
On 7/21/22 12:18, Richard Biener wrote:
> Can you also push this to active branches please?
Sure, I've just done that.
Cheers,
Martin
On Mon, Jul 11, 2022 at 10:05 PM Martin Liška wrote:
>
> I'm going to push the following cherry-pick which fixes libasan
> build with top-of-tree glibc.
Can you also push this to active branches please?
> Martin
>
> 9cf13067cb5088626ba7ee1ec4c42ec59c7995a0 [sanitizer] Remove #include
> to reso
I'm going to push the following cherry-pick which fixes libasan
build with top-of-tree glibc.
Martin
9cf13067cb5088626ba7ee1ec4c42ec59c7995a0 [sanitizer] Remove #include
to resolve fsconfig_command/mount_attr conflict with glibc 2.36
---
.../sanitizer_platform_limits_posix.cpp|
When we use cross toolchains, in which the GCC libraries are not installed
within a designated system root, the shared sanitizer libraries link against
libstdc++.so* within the same libraries. This directory, however, is not in
RPATH,
so attempting to build a dynamically linked application with
Again, please send patch as plain text.
On Fri, 2022-07-01 at 08:18 +, Dimitrije Milosevic wrote:
> When we use cross toolchains, in which the GCC libraries are not
> installed within a designated system root, the shared sanitizer
> libraries link against libstdc++.so* within the same librarie
When we use cross toolchains, in which the GCC libraries are not installed
within a designated system root, the shared sanitizer libraries link against
libstdc++.so* within the same libraries. This directory, however, is not in
RPATH, so attempting to build a dynamically linked application with
In libsanitizer code, the size of some GNU libc data structure (notably,
struct stat) is hard coded. These sizes may trigger a static assert
buidling against another libc.
Just make non-GNU libc targets UNSUPPORTED now. If someone really cares
about those alternative libc implementations, please
Pushed as it's only cherry-pick that fixes the following
rpmlint issue:
libtsan2.s390x: E: executable-stack (Badness: 1) /usr/lib64/libtsan.so.2.0.0
I'm going to take it also to gcc-12 branch.
Cheers,
Martin
791e0d1bc85d: [compiler-rt] Add NO_EXEC_STACK_DIRECTIVE on s390x
---
libsanitizer
On Thu, May 5, 2022 at 2:02 PM H.J. Lu wrote:
>
> cherry-pick:
>
> b226894d475b [sanitizer] [sanitizer] Correct GetTls for x32
> ---
> libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libsanitizer/sanitizer_common/sanitizer_lin
cherry-pick:
b226894d475b [sanitizer] [sanitizer] Correct GetTls for x32
---
libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
b/libsanitizer/sanitizer_common/sanitizer_linux
On Thu, May 5, 2022 at 11:28 AM Martin Liška wrote:
>
> On 5/5/22 18:21, H.J. Lu wrote:
> > On Thu, May 5, 2022 at 4:24 AM Martin Liška wrote:
> >>
> >> On 5/5/22 01:07, H.J. Lu wrote:
> >>> On Wed, May 4, 2022 at 1:59 AM Martin Liška wrote:
>
> Hello.
>
> I'm going to do mer
On 5/5/22 18:21, H.J. Lu wrote:
> On Thu, May 5, 2022 at 4:24 AM Martin Liška wrote:
>>
>> On 5/5/22 01:07, H.J. Lu wrote:
>>> On Wed, May 4, 2022 at 1:59 AM Martin Liška wrote:
Hello.
I'm going to do merge from upstream.
Patch can bootstrap on x86_64-linux-gnu and s
On Thu, May 5, 2022 at 4:24 AM Martin Liška wrote:
>
> On 5/5/22 01:07, H.J. Lu wrote:
> > On Wed, May 4, 2022 at 1:59 AM Martin Liška wrote:
> >>
> >> Hello.
> >>
> >> I'm going to do merge from upstream.
> >>
> >> Patch can bootstrap on x86_64-linux-gnu and survives regression
> >> tests. I've
On 5/5/22 01:07, H.J. Lu wrote:
> On Wed, May 4, 2022 at 1:59 AM Martin Liška wrote:
>>
>> Hello.
>>
>> I'm going to do merge from upstream.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression
>> tests. I've also tested on ppc64le-linux-gnu and verified the ABI.
>>
>> The onl
newfstatat for x32
to restore x32 build.
--
H.J.
From ae90c2d0f9bcc30af98c730f91544efa01cb897c Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Wed, 4 May 2022 15:59:49 -0700
Subject: [PATCH] libsanitizer: cherry-pick commit f52e365092aa from upstream
cherry-pick:
f52e365092aa [sanitizer] Use newfstatat for x32
All platforms return the main executable as the first dl_phdr_info.
FreeBSD, NetBSD, Solaris, and Linux-musl place the executable name
in the dlpi_name field of this entry. It appears that only Linux-glibc
uses the empty string.
To make this work generically on all platforms, unconditionally
skip
On Mon, Jan 3, 2022 at 6:06 AM Richard Biener
wrote:
>
> On Fri, Dec 17, 2021 at 11:45 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > OK for release branches?
>
> OK - I assume the size is not leaked as ABI detail?
No, it is not. I am checking it into GCC 11 and will backport
it to GCC 10/9 branch
On Fri, Dec 17, 2021 at 11:45 PM H.J. Lu via Gcc-patches
wrote:
>
> OK for release branches?
OK - I assume the size is not leaked as ABI detail?
>
> H.J.
> ---
> Cherry-pick from LLVM release/13.x branch:
>
> commit d96358a2819399a2abb60ad3b26444ab7b4409cf
> Author: Michał Górny
> Date: Mon D
On 12/22/21 22:09, Azat Khuzhin via Gcc-patches wrote:
So what is the right way here?
- migrate all tests
- write test only for setbuffer()
- do not add any tests, since they are covered in llvm repo
Hello.
Yes, we don't automatically sync sanitizer tests when we merge from master.
Historicall
On Wed, Dec 22, 2021 at 10:02:02PM +0100, Bernhard Reutner-Fischer wrote:
> You should state how you tested the patch. Please refer to
> https://gcc.gnu.org/contribute.html#testing
I though about this, but when gcc syncs changes with upstream [1], it
does not syncs tests, even though they were the
On Wed, 22 Dec 2021 23:50:39 +0300
Azat Khuzhin wrote:
> Thanks!
you're welcome.
You should state how you tested the patch. Please refer to
https://gcc.gnu.org/contribute.html#testing
thanks,
On Wed, Dec 22, 2021 at 09:41:06PM +0100, Bernhard Reutner-Fischer wrote:
> On 22 December 2021 19:19:12 CET, Azat Khuzhin via Gcc-patches
> wrote:
> >- COMMON_INTERCEPTOR_ENTER(ctx, setbuffer, stream, buf, mode);
> >+ COMMON_INTERCEPTOR_ENTER(ctx, setbuffer, stream, buf, size);
> > REAL(setb
On Wed, Dec 22, 2021 at 09:41:06PM +0100, Bernhard Reutner-Fischer wrote:
> On 22 December 2021 19:19:12 CET, Azat Khuzhin via Gcc-patches
> wrote:
> >Fixes: b667dd7017a ("Libsanitizer merge from trunk r368656.")
> >Refs: https://reviews.llvm.org/D116176
> >---
> > .../sanitizer_common/sanitizer_
On 22 December 2021 19:19:12 CET, Azat Khuzhin via Gcc-patches
wrote:
>Fixes: b667dd7017a ("Libsanitizer merge from trunk r368656.")
>Refs: https://reviews.llvm.org/D116176
>---
> .../sanitizer_common/sanitizer_common_interceptors.inc | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions
Fixes: b667dd7017a ("Libsanitizer merge from trunk r368656.")
Refs: https://reviews.llvm.org/D116176
---
.../sanitizer_common/sanitizer_common_interceptors.inc | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libsanitizer/sanitizer_common/sanitizer_common_interceptors
OK for release branches?
H.J.
---
Cherry-pick from LLVM release/13.x branch:
commit d96358a2819399a2abb60ad3b26444ab7b4409cf
Author: Michał Górny
Date: Mon Dec 13 22:28:26 2021 +0100
[compiler-rt] Increase kDlsymAllocPoolSize to fix test failures
Increase kDlsymAllocPoolSize on the
On Tue, Nov 30, 2021 at 06:20:09AM -0800, H.J. Lu via Gcc-patches wrote:
> Use SSE, instead of AVX, to save and restore XMM registers to support
> processors without AVX. The affected codes are unused in upstream since
>
> https://github.com/llvm/llvm-project/commit/66d4ce7e26a5
>
> and will be
Use SSE, instead of AVX, to save and restore XMM registers to support
processors without AVX. The affected codes are unused in upstream since
https://github.com/llvm/llvm-project/commit/66d4ce7e26a5
and will be removed in
https://reviews.llvm.org/D112604
This fixed
FAIL: g++.dg/tsan/pthread_c
On Wed, 17 Nov 2021, Jakub Jelinek wrote:
> On Mon, Nov 08, 2021 at 08:50:41AM +0100, Gerald Pfeifer wrote:
> > This is the first part I committed on Friday, the second will
> > follow today.
>
> Here is an alternative to the patch changing a file imported from
> compiler-rt upstream, so that we
On Mon, Nov 08, 2021 at 08:50:41AM +0100, Gerald Pfeifer wrote:
> This is the first part I committed on Friday, the second will
> follow today.
Here is an alternative to the patch changing a file imported from
compiler-rt upstream, so that we don't need to cary a local patch for that
particular p
1 - 100 of 204 matches
Mail list logo
