Re: [PATCH] libsanitizer: Do not mention MSan and DFSan in an error message

2024-04-04 Thread Andreas Krebbel
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_linux_s390.cpp (AvoidCVE_2016_2143):
>>> Do not mention MSan and DFSan, which are not supported by GCC.
>>
>> Ok, Thanks!
> 
> This then needs to be added to libsanitizer/LOCAL_PATCHES , otherwise
> it will disappear on the next merge from upstream.
> 
> Though, I must say I'm not entirely convinced the change is worth the
> hassle on every libsanitizer merge.

You are right. We will leave the message as is.

Thanks!

Andreas

> 
>>> diff --git a/libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp 
>>> b/libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp
>>> index 74db831b0aa..65ba825fa97 100644
>>> --- a/libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp
>>> +++ b/libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp
>>> @@ -212,7 +212,7 @@ void AvoidCVE_2016_2143() {
>>>  return;
>>>Report(
>>>  "ERROR: Your kernel seems to be vulnerable to CVE-2016-2143.  Using 
>>> ASan,\n"
>>> -"MSan, TSan, DFSan or LSan with such kernel can and will crash your\n"
>>> +"TSan or LSan with such kernel can and will crash your\n"
>>>  "machine, or worse.\n"
>>>  "\n"
>>>  "If you are certain your kernel is not vulnerable (you have compiled 
>>> it\n"
> 
>   Jakub
> 



Re: [PATCH] libsanitizer: Do not mention MSan and DFSan in an error message

2024-04-04 Thread Jakub Jelinek
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):
> > Do not mention MSan and DFSan, which are not supported by GCC.
> 
> Ok, Thanks!

This then needs to be added to libsanitizer/LOCAL_PATCHES , otherwise
it will disappear on the next merge from upstream.

Though, I must say I'm not entirely convinced the change is worth the
hassle on every libsanitizer merge.

> > diff --git a/libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp 
> > b/libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp
> > index 74db831b0aa..65ba825fa97 100644
> > --- a/libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp
> > +++ b/libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp
> > @@ -212,7 +212,7 @@ void AvoidCVE_2016_2143() {
> >  return;
> >Report(
> >  "ERROR: Your kernel seems to be vulnerable to CVE-2016-2143.  Using 
> > ASan,\n"
> > -"MSan, TSan, DFSan or LSan with such kernel can and will crash your\n"
> > +"TSan or LSan with such kernel can and will crash your\n"
> >  "machine, or worse.\n"
> >  "\n"
> >  "If you are certain your kernel is not vulnerable (you have compiled 
> > it\n"

Jakub



Re: [PATCH] libsanitizer: Do not mention MSan and DFSan in an error message

2024-04-04 Thread Andreas Krebbel
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, Thanks!

Andreas

> ---
>  libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp 
> b/libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp
> index 74db831b0aa..65ba825fa97 100644
> --- a/libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp
> +++ b/libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp
> @@ -212,7 +212,7 @@ void AvoidCVE_2016_2143() {
>  return;
>Report(
>  "ERROR: Your kernel seems to be vulnerable to CVE-2016-2143.  Using 
> ASan,\n"
> -"MSan, TSan, DFSan or LSan with such kernel can and will crash your\n"
> +"TSan or LSan with such kernel can and will crash your\n"
>  "machine, or worse.\n"
>  "\n"
>  "If you are certain your kernel is not vulnerable (you have compiled 
> it\n"



[PATCH] libsanitizer: Do not mention MSan and DFSan in an error message

2024-04-04 Thread Ilya Leoshkevich
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 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp 
b/libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp
index 74db831b0aa..65ba825fa97 100644
--- a/libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp
@@ -212,7 +212,7 @@ void AvoidCVE_2016_2143() {
 return;
   Report(
 "ERROR: Your kernel seems to be vulnerable to CVE-2016-2143.  Using 
ASan,\n"
-"MSan, TSan, DFSan or LSan with such kernel can and will crash your\n"
+"TSan or LSan with such kernel can and will crash your\n"
 "machine, or worse.\n"
 "\n"
 "If you are certain your kernel is not vulnerable (you have compiled it\n"
-- 
2.44.0



Re: [PATCH] libsanitizer: Intercept __makecontext_v2 on Solaris/SPARC [PR113785]

2024-02-16 Thread Rainer Orth
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++-common/asan/swapcontext-test-1.c   -O2  execution test
>> FAIL: c-c++-common/asan/swapcontext-test-1.c   -O2 -flto  execution test
>> FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 -flto
>> -flto-partition=none execution test
>> FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -fomit-frame-pointer
>> -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
>> FAIL: c-c++-common/asan/swapcontext-test-1.c   -O3 -g  execution test
>> FAIL: c-c++-common/asan/swapcontext-test-1.c   -Os  execution test
>> 
>> As detailed in PR sanitizer/113785, this happens because an ABI change
>> in Solaris 10/SPARC caused the external symbol for makecontext to be
>> changed to __makecontext_v2, which isn't intercepted.
>
> Is Solaris 9/SPARC and earlier no longer supported in GCC?

no, Solaris 9 support was removed in GCC 5 already.  The only version
supported by trunk is 11.4; 11.3 isn't but I won't actually remove
support until Solaris 11.4 systems have been added to the cfarm (which
should be soon).

> If so, ok for trunk.

Thanks.

> Otherwise I'd expect some ifdefs or whatever to check if it is
> Solaris 10+ with __makecontext_v2 or Solaris up to 9 with makecontext.

True.  However, it can be difficult to get patches upstream for OS
versions not remotely supported in LLVM (which has been 11.4-only for
years).

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [PATCH] libsanitizer: Intercept __makecontext_v2 on Solaris/SPARC [PR113785]

2024-02-16 Thread Jakub Jelinek
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/swapcontext-test-1.c   -O2  execution test
> FAIL: c-c++-common/asan/swapcontext-test-1.c   -O2 -flto  execution test
> FAIL: c-c++-common/asan/swapcontext-test-1.c   -O2 -flto -flto-partition=none 
>  execution test
> FAIL: c-c++-common/asan/swapcontext-test-1.c   -O3 -fomit-frame-pointer 
> -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
> FAIL: c-c++-common/asan/swapcontext-test-1.c   -O3 -g  execution test
> FAIL: c-c++-common/asan/swapcontext-test-1.c   -Os  execution test
> 
> As detailed in PR sanitizer/113785, this happens because an ABI change
> in Solaris 10/SPARC caused the external symbol for makecontext to be
> changed to __makecontext_v2, which isn't intercepted.

Is Solaris 9/SPARC and earlier no longer supported in GCC?

If so, ok for trunk.

Otherwise I'd expect some ifdefs or whatever to check if it is
Solaris 10+ with __makecontext_v2 or Solaris up to 9 with makecontext.

Jakub



[PATCH] libsanitizer: Intercept __makecontext_v2 on Solaris/SPARC [PR113785]

2024-02-16 Thread Rainer Orth
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/swapcontext-test-1.c   -O2 -flto  execution test
FAIL: c-c++-common/asan/swapcontext-test-1.c   -O2 -flto -flto-partition=none  
execution test
FAIL: c-c++-common/asan/swapcontext-test-1.c   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: c-c++-common/asan/swapcontext-test-1.c   -O3 -g  execution test
FAIL: c-c++-common/asan/swapcontext-test-1.c   -Os  execution test

As detailed in PR sanitizer/113785, this happens because an ABI change
in Solaris 10/SPARC caused the external symbol for makecontext to be
changed to __makecontext_v2, which isn't intercepted.

The following patch, submitted upstream at
https://github.com/llvm/llvm-project/pull/81588, fixes that.

Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11.

Ok to cherry-pick into trunk?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2024-02-16  Rainer Orth  

libsanitizer:
PR sanitizer/113785
* sanitizer_common/asan/asan_interceptors.cpp: Cherry-pick
llvm-project revision 8c2033719a843a1880427a5e8caa5563248bce78.

# HG changeset patch
# Parent  2fb800df7e0fd2d03a485601ad4683a29f78f2a4
libsanitizer: Intercept __makecontext_v2 on Solaris/SPARC [PR113785]

diff --git a/libsanitizer/asan/asan_interceptors.cpp b/libsanitizer/asan/asan_interceptors.cpp
--- a/libsanitizer/asan/asan_interceptors.cpp
+++ b/libsanitizer/asan/asan_interceptors.cpp
@@ -347,8 +347,16 @@ static void ClearShadowMemoryForContextS
   PoisonShadow(bottom, ssize, 0);
 }
 
+// Since Solaris 10/SPARC, ucp->uc_stack.ss_sp refers to the stack base address
+// as on other targets.  For binary compatibility, the new version uses a
+// different external name, so we intercept that.
+#if SANITIZER_SOLARIS && defined(__sparc__)
+INTERCEPTOR(void, __makecontext_v2, struct ucontext_t *ucp, void (*func)(),
+int argc, ...) {
+#else
 INTERCEPTOR(void, makecontext, struct ucontext_t *ucp, void (*func)(), int argc,
 ...) {
+#endif
   va_list ap;
   uptr args[64];
   // We don't know a better way to forward ... into REAL function. We can
@@ -368,7 +376,11 @@ INTERCEPTOR(void, makecontext, struct uc
   ENUMERATE_ARRAY_16(0), ENUMERATE_ARRAY_16(16), ENUMERATE_ARRAY_16(32), \
   ENUMERATE_ARRAY_16(48)
 
+#if SANITIZER_SOLARIS && defined(__sparc__)
+  REAL(__makecontext_v2)
+#else
   REAL(makecontext)
+#endif
   ((struct ucontext_t *)ucp, func, argc, ENUMERATE_ARRAY_64());
 
 #undef ENUMERATE_ARRAY_4
@@ -783,7 +795,12 @@ void InitializeAsanInterceptors() {
 
 #  if ASAN_INTERCEPT_SWAPCONTEXT
   ASAN_INTERCEPT_FUNC(swapcontext);
+  // See the makecontext interceptor above for an explanation.
+#if SANITIZER_SOLARIS && defined(__sparc__)
+  ASAN_INTERCEPT_FUNC(__makecontext_v2);
+#else
   ASAN_INTERCEPT_FUNC(makecontext);
+#endif
 #  endif
 #  if ASAN_INTERCEPT__LONGJMP
   ASAN_INTERCEPT_FUNC(_longjmp);


Re: [PATCH] libsanitizer: workaround libtool error when building in Yocto Kirkstone

2024-02-06 Thread Alibek Omarov
Thanks for quick reply!

If it's an inappropriate patch for GCC, should I try to send it to Yocto then?

Alibek.


Re: [PATCH] libsanitizer: workaround libtool error when building in Yocto Kirkstone

2024-02-06 Thread Andrew Pinski
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 avoid the issue.

This seems like an OE/Yocto issue as updating libtool inside GCC is
going to be problematic due to some local GCC patches to libtool and
some conflicts between libtool and GCC's understanding of --sysroot.

See https://gcc.gnu.org/legacy-ml/gcc-patches/2013-08/msg01465.html
(yes 10 years ago but as far as I Know this still applies).

Thanks,
Andrew Pinski

>
> Signed-off-by: Alibek Omarov 
>
> ---
>  libsanitizer/asan/Makefile.in   | 2 +-
>  libsanitizer/hwasan/Makefile.in | 2 +-
>  libsanitizer/tsan/Makefile.in   | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libsanitizer/asan/Makefile.in b/libsanitizer/asan/Makefile.in
> index 25c7fd7b7..5992bafd3 100644
> --- a/libsanitizer/asan/Makefile.in
> +++ b/libsanitizer/asan/Makefile.in
> @@ -188,7 +188,7 @@ am__depfiles_maybe = depfiles
>  am__mv = mv -f
>  CPPASCOMPILE = $(CCAS) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
> $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CCASFLAGS) $(CCASFLAGS)
> -LTCPPASCOMPILE = $(LIBTOOL) $(AM_V_lt) $(AM_LIBTOOLFLAGS) \
> +LTCPPASCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
> $(LIBTOOLFLAGS) --mode=compile $(CCAS) $(DEFS) \
> $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
> $(AM_CCASFLAGS) $(CCASFLAGS)
> diff --git a/libsanitizer/hwasan/Makefile.in b/libsanitizer/hwasan/Makefile.in
> index 542af8f19..a000fe570 100644
> --- a/libsanitizer/hwasan/Makefile.in
> +++ b/libsanitizer/hwasan/Makefile.in
> @@ -180,7 +180,7 @@ am__depfiles_maybe = depfiles
>  am__mv = mv -f
>  CPPASCOMPILE = $(CCAS) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
> $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CCASFLAGS) $(CCASFLAGS)
> -LTCPPASCOMPILE = $(LIBTOOL) $(AM_V_lt) $(AM_LIBTOOLFLAGS) \
> +LTCPPASCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
> $(LIBTOOLFLAGS) --mode=compile $(CCAS) $(DEFS) \
> $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
> $(AM_CCASFLAGS) $(CCASFLAGS)
> diff --git a/libsanitizer/tsan/Makefile.in b/libsanitizer/tsan/Makefile.in
> index ce11d2497..40d39e31d 100644
> --- a/libsanitizer/tsan/Makefile.in
> +++ b/libsanitizer/tsan/Makefile.in
> @@ -184,7 +184,7 @@ am__depfiles_maybe = depfiles
>  am__mv = mv -f
>  CPPASCOMPILE = $(CCAS) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
> $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CCASFLAGS) $(CCASFLAGS)
> -LTCPPASCOMPILE = $(LIBTOOL) $(AM_V_lt) $(AM_LIBTOOLFLAGS) \
> +LTCPPASCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
> $(LIBTOOLFLAGS) --mode=compile $(CCAS) $(DEFS) \
> $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
> $(AM_CCASFLAGS) $(CCASFLAGS)
> --
> 2.34.1
>


[PATCH] libsanitizer: workaround libtool error when building in Yocto Kirkstone

2024-02-06 Thread Alibek Omarov
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/asan/Makefile.in   | 2 +-
 libsanitizer/hwasan/Makefile.in | 2 +-
 libsanitizer/tsan/Makefile.in   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libsanitizer/asan/Makefile.in b/libsanitizer/asan/Makefile.in
index 25c7fd7b7..5992bafd3 100644
--- a/libsanitizer/asan/Makefile.in
+++ b/libsanitizer/asan/Makefile.in
@@ -188,7 +188,7 @@ am__depfiles_maybe = depfiles
 am__mv = mv -f
 CPPASCOMPILE = $(CCAS) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CCASFLAGS) $(CCASFLAGS)
-LTCPPASCOMPILE = $(LIBTOOL) $(AM_V_lt) $(AM_LIBTOOLFLAGS) \
+LTCPPASCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
$(LIBTOOLFLAGS) --mode=compile $(CCAS) $(DEFS) \
$(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
$(AM_CCASFLAGS) $(CCASFLAGS)
diff --git a/libsanitizer/hwasan/Makefile.in b/libsanitizer/hwasan/Makefile.in
index 542af8f19..a000fe570 100644
--- a/libsanitizer/hwasan/Makefile.in
+++ b/libsanitizer/hwasan/Makefile.in
@@ -180,7 +180,7 @@ am__depfiles_maybe = depfiles
 am__mv = mv -f
 CPPASCOMPILE = $(CCAS) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CCASFLAGS) $(CCASFLAGS)
-LTCPPASCOMPILE = $(LIBTOOL) $(AM_V_lt) $(AM_LIBTOOLFLAGS) \
+LTCPPASCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
$(LIBTOOLFLAGS) --mode=compile $(CCAS) $(DEFS) \
$(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
$(AM_CCASFLAGS) $(CCASFLAGS)
diff --git a/libsanitizer/tsan/Makefile.in b/libsanitizer/tsan/Makefile.in
index ce11d2497..40d39e31d 100644
--- a/libsanitizer/tsan/Makefile.in
+++ b/libsanitizer/tsan/Makefile.in
@@ -184,7 +184,7 @@ am__depfiles_maybe = depfiles
 am__mv = mv -f
 CPPASCOMPILE = $(CCAS) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CCASFLAGS) $(CCASFLAGS)
-LTCPPASCOMPILE = $(LIBTOOL) $(AM_V_lt) $(AM_LIBTOOLFLAGS) \
+LTCPPASCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
$(LIBTOOLFLAGS) --mode=compile $(CCAS) $(DEFS) \
$(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
$(AM_CCASFLAGS) $(CCASFLAGS)
-- 
2.34.1



RE: [PATCH][libsanitizer]: Sync fixes for asan interceptors from upstream [PR112644]

2024-01-31 Thread Tamar Christina
> -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 for asan interceptors from 
> upstream
> [PR112644]
> 
> On Mon, Jan 29, 2024 at 7:04 AM Tamar Christina 
> wrote:
> >
> > Hi All,
> >
> > This cherry-picks and squashes the differences between commits
> >
> >
> d3e5c20ab846303874a2a25e5877c72271fc798b..76e1e45922e6709392fb82aa
> c44bebe3dbc2ea63
> > 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 in the PR the last sync brought in a bug from upstream[1] where
> > operations became non-recoverable and as such the tests in AArch64 started
> > failing.  This cherry picks the fix and there are minor updates needed to 
> > GCC
> > after this to fix the cases.
> >
> > [1] https://github.com/llvm/llvm-project/pull/74000
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> >
> > Ok for master?
> 
> Thanks for handling this; though I wonder how this slipped through
> testing upstream in LLVM. I see they added some new testcases for
> this. I Know GCC's testsuite for sanitizer is slightly different from
> LLVM's. Is it the case, GCC has more tests in this area? Is someone
> adding the testcases that GCC has in this area upstream to LLVM;
> basically so merging won't bring in regressions like this in the
> future?

There were two parts here.  The first one is that their testsuite didn't have 
any
test for the recovery case.  Which they've now added.

But the second parts (which I'm not posting patches for) is that the change
In hwasan means that the runtime can now instrument some additional
library methods which it couldn't before.  And GCC now needs to not inline
these anymore.

This does mean that on future updates one needs to take a look at the
Instrumentation list and make sure to keep it in sync with GCC's otherwise
we'll lose instrumentation.

Regards,
Tamar
> 
> Thanks,
> Andrew
> 
> >
> > Thanks,
> > Tamar
> >
> > libsanitizer/ChangeLog:
> >
> > PR sanitizer/112644
> > * hwasan/hwasan_interceptors.cpp (ACCESS_MEMORY_RANGE,
> > HWASAN_READ_RANGE, HWASAN_WRITE_RANGE,
> COMMON_SYSCALL_PRE_READ_RANGE,
> > COMMON_SYSCALL_PRE_WRITE_RANGE,
> COMMON_INTERCEPTOR_WRITE_RANGE,
> > COMMON_INTERCEPTOR_READ_RANGE): Make recoverable.
> >
> > --- inline copy of patch --
> > diff --git a/libsanitizer/hwasan/hwasan_interceptors.cpp
> b/libsanitizer/hwasan/hwasan_interceptors.cpp
> > index
> d9237cf9b8e3bf982cf213123ef22e73ec027c9e..96df4dd0c24d7d3db28fa2557
> cf63da0f295e33f 100644
> > --- a/libsanitizer/hwasan/hwasan_interceptors.cpp
> > +++ b/libsanitizer/hwasan/hwasan_interceptors.cpp
> > @@ -36,16 +36,16 @@ struct HWAsanInterceptorContext {
> >const char *interceptor_name;
> >  };
> >
> > -#  define ACCESS_MEMORY_RANGE(ctx, offset, size, access)   
> >  \
> > -do {   
> >  \
> > -  __hwasan::CheckAddressSized > access>((uptr)offset, \
> > -  size);   
> >  \
> > +#  define ACCESS_MEMORY_RANGE(offset, size, access)
> >\
> > +do {   
> >\
> > +  __hwasan::CheckAddressSized > access>((uptr)offset, \
> > +size); 
> >\
> >  } while (0)
> >
> > -#  define HWASAN_READ_RANGE(ctx, offset, size) \
> > -ACCESS_MEMORY_RANGE(ctx, offset, size, AccessType::Load)
> > -#  define HWASAN_WRITE_RANGE(ctx, offset, size) \
> > -ACCESS_MEMORY_RANGE(ctx, offset, size, AccessType::Store)
> > +#  define HWASAN_READ_RANGE(offset, size) \
> > +ACCESS_MEMORY_RANGE(offset, size, AccessType::Load)
> > +#  define HWASAN_WRITE_RANGE(offset, size) \
> > +ACCESS_MEMORY_RANGE(offset, size, AccessType::Store)
> >
> >  #  if !SANITIZER_APPLE
> >  #define HWASAN_INTERCEPT_FUNC(name)
> > \
> > @@ -74,9 +74,8 @@ struct HWAsanInterceptorContext {
> >
> >  #  if HWASAN_WITH_INTERCEPTORS
> >
> > -#define COMMON_SYSC

Re: [PATCH][libsanitizer]: Sync fixes for asan interceptors from upstream [PR112644]

2024-01-29 Thread Andrew Pinski
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 relevant
> for GCC.
>
> This is required to fix the linked PR.
>
> As mentioned in the PR the last sync brought in a bug from upstream[1] where
> operations became non-recoverable and as such the tests in AArch64 started
> failing.  This cherry picks the fix and there are minor updates needed to GCC
> after this to fix the cases.
>
> [1] https://github.com/llvm/llvm-project/pull/74000
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?

Thanks for handling this; though I wonder how this slipped through
testing upstream in LLVM. I see they added some new testcases for
this. I Know GCC's testsuite for sanitizer is slightly different from
LLVM's. Is it the case, GCC has more tests in this area? Is someone
adding the testcases that GCC has in this area upstream to LLVM;
basically so merging won't bring in regressions like this in the
future?

Thanks,
Andrew

>
> Thanks,
> Tamar
>
> libsanitizer/ChangeLog:
>
> PR sanitizer/112644
> * hwasan/hwasan_interceptors.cpp (ACCESS_MEMORY_RANGE,
> HWASAN_READ_RANGE, HWASAN_WRITE_RANGE, COMMON_SYSCALL_PRE_READ_RANGE,
> COMMON_SYSCALL_PRE_WRITE_RANGE, COMMON_INTERCEPTOR_WRITE_RANGE,
> COMMON_INTERCEPTOR_READ_RANGE): Make recoverable.
>
> --- inline copy of patch --
> diff --git a/libsanitizer/hwasan/hwasan_interceptors.cpp 
> b/libsanitizer/hwasan/hwasan_interceptors.cpp
> index 
> d9237cf9b8e3bf982cf213123ef22e73ec027c9e..96df4dd0c24d7d3db28fa2557cf63da0f295e33f
>  100644
> --- a/libsanitizer/hwasan/hwasan_interceptors.cpp
> +++ b/libsanitizer/hwasan/hwasan_interceptors.cpp
> @@ -36,16 +36,16 @@ struct HWAsanInterceptorContext {
>const char *interceptor_name;
>  };
>
> -#  define ACCESS_MEMORY_RANGE(ctx, offset, size, access)\
> -do {\
> -  __hwasan::CheckAddressSized((uptr)offset, \
> -  size);\
> +#  define ACCESS_MEMORY_RANGE(offset, size, access)  
>  \
> +do { 
>  \
> +  __hwasan::CheckAddressSized access>((uptr)offset, \
> +size);   
>  \
>  } while (0)
>
> -#  define HWASAN_READ_RANGE(ctx, offset, size) \
> -ACCESS_MEMORY_RANGE(ctx, offset, size, AccessType::Load)
> -#  define HWASAN_WRITE_RANGE(ctx, offset, size) \
> -ACCESS_MEMORY_RANGE(ctx, offset, size, AccessType::Store)
> +#  define HWASAN_READ_RANGE(offset, size) \
> +ACCESS_MEMORY_RANGE(offset, size, AccessType::Load)
> +#  define HWASAN_WRITE_RANGE(offset, size) \
> +ACCESS_MEMORY_RANGE(offset, size, AccessType::Store)
>
>  #  if !SANITIZER_APPLE
>  #define HWASAN_INTERCEPT_FUNC(name)  
>   \
> @@ -74,9 +74,8 @@ struct HWAsanInterceptorContext {
>
>  #  if HWASAN_WITH_INTERCEPTORS
>
> -#define COMMON_SYSCALL_PRE_READ_RANGE(p, s) __hwasan_loadN((uptr)p, 
> (uptr)s)
> -#define COMMON_SYSCALL_PRE_WRITE_RANGE(p, s) \
> -  __hwasan_storeN((uptr)p, (uptr)s)
> +#define COMMON_SYSCALL_PRE_READ_RANGE(p, s) HWASAN_READ_RANGE(p, s)
> +#define COMMON_SYSCALL_PRE_WRITE_RANGE(p, s) HWASAN_WRITE_RANGE(p, s)
>  #define COMMON_SYSCALL_POST_READ_RANGE(p, s) \
>do {   \
>  (void)(p);   \
> @@ -91,10 +90,10 @@ struct HWAsanInterceptorContext {
>  #include "sanitizer_common/sanitizer_syscalls_netbsd.inc"
>
>  #define COMMON_INTERCEPTOR_WRITE_RANGE(ctx, ptr, size) \
> -  HWASAN_WRITE_RANGE(ctx, ptr, size)
> +  HWASAN_WRITE_RANGE(ptr, size)
>
>  #define COMMON_INTERCEPTOR_READ_RANGE(ctx, ptr, size) \
> -  HWASAN_READ_RANGE(ctx, ptr, size)
> +  HWASAN_READ_RANGE(ptr, size)
>
>  #define COMMON_INTERCEPTOR_ENTER(ctx, func, ...) \
>HWAsanInterceptorContext _ctx = {#func};   \
>
>
>
>
> --


Re: [PATCH][libsanitizer]: Sync fixes for asan interceptors from upstream [PR112644]

2024-01-29 Thread Jakub Jelinek
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 changes relevant
> for GCC.
> 
> This is required to fix the linked PR.
> 
> As mentioned in the PR the last sync brought in a bug from upstream[1] where
> operations became non-recoverable and as such the tests in AArch64 started
> failing.  This cherry picks the fix and there are minor updates needed to GCC
> after this to fix the cases.
> 
> [1] https://github.com/llvm/llvm-project/pull/74000
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> 
> Ok for master?
> 
> Thanks,
> Tamar
> 
> libsanitizer/ChangeLog:
> 
>   PR sanitizer/112644
>   * hwasan/hwasan_interceptors.cpp (ACCESS_MEMORY_RANGE,
>   HWASAN_READ_RANGE, HWASAN_WRITE_RANGE, COMMON_SYSCALL_PRE_READ_RANGE,
>   COMMON_SYSCALL_PRE_WRITE_RANGE, COMMON_INTERCEPTOR_WRITE_RANGE,
>   COMMON_INTERCEPTOR_READ_RANGE): Make recoverable.

The normal ChangeLog entry for this would be
Cherry-pick llvm-project revision XYZ and UVW.

Ok for trunk with that changed.

Jakub



[PATCH][libsanitizer]: Sync fixes for asan interceptors from upstream [PR112644]

2024-01-29 Thread Tamar Christina
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 in the PR the last sync brought in a bug from upstream[1] where
operations became non-recoverable and as such the tests in AArch64 started
failing.  This cherry picks the fix and there are minor updates needed to GCC
after this to fix the cases.

[1] https://github.com/llvm/llvm-project/pull/74000

Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.

Ok for master?

Thanks,
Tamar

libsanitizer/ChangeLog:

PR sanitizer/112644
* hwasan/hwasan_interceptors.cpp (ACCESS_MEMORY_RANGE,
HWASAN_READ_RANGE, HWASAN_WRITE_RANGE, COMMON_SYSCALL_PRE_READ_RANGE,
COMMON_SYSCALL_PRE_WRITE_RANGE, COMMON_INTERCEPTOR_WRITE_RANGE,
COMMON_INTERCEPTOR_READ_RANGE): Make recoverable.

--- inline copy of patch -- 
diff --git a/libsanitizer/hwasan/hwasan_interceptors.cpp 
b/libsanitizer/hwasan/hwasan_interceptors.cpp
index 
d9237cf9b8e3bf982cf213123ef22e73ec027c9e..96df4dd0c24d7d3db28fa2557cf63da0f295e33f
 100644
--- a/libsanitizer/hwasan/hwasan_interceptors.cpp
+++ b/libsanitizer/hwasan/hwasan_interceptors.cpp
@@ -36,16 +36,16 @@ struct HWAsanInterceptorContext {
   const char *interceptor_name;
 };
 
-#  define ACCESS_MEMORY_RANGE(ctx, offset, size, access)\
-do {\
-  __hwasan::CheckAddressSized((uptr)offset, \
-  size);\
+#  define ACCESS_MEMORY_RANGE(offset, size, access)   \
+do {  \
+  __hwasan::CheckAddressSized((uptr)offset, \
+size);\
 } while (0)
 
-#  define HWASAN_READ_RANGE(ctx, offset, size) \
-ACCESS_MEMORY_RANGE(ctx, offset, size, AccessType::Load)
-#  define HWASAN_WRITE_RANGE(ctx, offset, size) \
-ACCESS_MEMORY_RANGE(ctx, offset, size, AccessType::Store)
+#  define HWASAN_READ_RANGE(offset, size) \
+ACCESS_MEMORY_RANGE(offset, size, AccessType::Load)
+#  define HWASAN_WRITE_RANGE(offset, size) \
+ACCESS_MEMORY_RANGE(offset, size, AccessType::Store)
 
 #  if !SANITIZER_APPLE
 #define HWASAN_INTERCEPT_FUNC(name)
\
@@ -74,9 +74,8 @@ struct HWAsanInterceptorContext {
 
 #  if HWASAN_WITH_INTERCEPTORS
 
-#define COMMON_SYSCALL_PRE_READ_RANGE(p, s) __hwasan_loadN((uptr)p, 
(uptr)s)
-#define COMMON_SYSCALL_PRE_WRITE_RANGE(p, s) \
-  __hwasan_storeN((uptr)p, (uptr)s)
+#define COMMON_SYSCALL_PRE_READ_RANGE(p, s) HWASAN_READ_RANGE(p, s)
+#define COMMON_SYSCALL_PRE_WRITE_RANGE(p, s) HWASAN_WRITE_RANGE(p, s)
 #define COMMON_SYSCALL_POST_READ_RANGE(p, s) \
   do {   \
 (void)(p);   \
@@ -91,10 +90,10 @@ struct HWAsanInterceptorContext {
 #include "sanitizer_common/sanitizer_syscalls_netbsd.inc"
 
 #define COMMON_INTERCEPTOR_WRITE_RANGE(ctx, ptr, size) \
-  HWASAN_WRITE_RANGE(ctx, ptr, size)
+  HWASAN_WRITE_RANGE(ptr, size)
 
 #define COMMON_INTERCEPTOR_READ_RANGE(ctx, ptr, size) \
-  HWASAN_READ_RANGE(ctx, ptr, size)
+  HWASAN_READ_RANGE(ptr, size)
 
 #define COMMON_INTERCEPTOR_ENTER(ctx, func, ...) \
   HWAsanInterceptorContext _ctx = {#func};   \




-- 
diff --git a/libsanitizer/hwasan/hwasan_interceptors.cpp 
b/libsanitizer/hwasan/hwasan_interceptors.cpp
index 
d9237cf9b8e3bf982cf213123ef22e73ec027c9e..96df4dd0c24d7d3db28fa2557cf63da0f295e33f
 100644
--- a/libsanitizer/hwasan/hwasan_interceptors.cpp
+++ b/libsanitizer/hwasan/hwasan_interceptors.cpp
@@ -36,16 +36,16 @@ struct HWAsanInterceptorContext {
   const char *interceptor_name;
 };
 
-#  define ACCESS_MEMORY_RANGE(ctx, offset, size, access)\
-do {\
-  __hwasan::CheckAddressSized((uptr)offset, \
-  size);\
+#  define ACCESS_MEMORY_RANGE(offset, size, access)   \
+do {  \
+  __hwasan::CheckAddressSized((uptr)offset, \
+size);\
 } while (0)
 
-#  define HWASAN_READ_RANGE(ctx, offset, size) \
-ACCESS_MEMORY_RANGE(ctx, offset, size, AccessType::Load)
-#  define HWASAN_WRITE_RANGE(ctx, offset, size) \
-ACCESS_MEMORY_RANGE(ctx, offset, size, AccessType::Store)
+#  define HWASAN_READ_RANGE(offset, size) \
+ACCESS_MEMORY_RANGE(offset, size, AccessType::Load)

Re: [PATCH] libsanitizer: Replace memcpy with internal version in sanitizer_common

2024-01-17 Thread Jakub Jelinek
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 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:
> > > 
> > >   * sanitizer_common/Makefile.am (DEFS): Add @AS_SYM_ASSIGN_DEFS@.
> > >   * sanitizer_common/Makefile.in: Regenerate.
> > 
> > Ok.
> 
> We have only been granted write approval for the SPARC port. Is it
> ok to push this anyway or could you help us with it?

I don't think anyone has write access only to a part of the git repository.
So, if you are Write After Approval (which seems you are according to
MAINTAINERS), you should be able to commit any patch approved by
maintainers or reviewers.

Jakub



Re: [PATCH] libsanitizer: Replace memcpy with internal version in sanitizer_common

2024-01-17 Thread Daniel Cederman

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_SYM_ASSIGN to replace it with a
call to __sanitizer_internal_memcpy.

libsanitizer/ChangeLog:

* sanitizer_common/Makefile.am (DEFS): Add @AS_SYM_ASSIGN_DEFS@.
* sanitizer_common/Makefile.in: Regenerate.


Ok.

Jakub



We have only been granted write approval for the SPARC port. Is it
ok to push this anyway or could you help us with it?

/Daniel


Re: [PATCH] libsanitizer: Replace memcpy with internal version in sanitizer_common

2024-01-16 Thread Jakub Jelinek
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 to __sanitizer_internal_memcpy.
> 
> libsanitizer/ChangeLog:
> 
>   * sanitizer_common/Makefile.am (DEFS): Add @AS_SYM_ASSIGN_DEFS@.
>   * sanitizer_common/Makefile.in: Regenerate.

Ok.

Jakub



[PATCH] libsanitizer: Replace memcpy with internal version in sanitizer_common

2024-01-16 Thread Daniel Cederman
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:

* sanitizer_common/Makefile.am (DEFS): Add @AS_SYM_ASSIGN_DEFS@.
* sanitizer_common/Makefile.in: Regenerate.
---
 libsanitizer/sanitizer_common/Makefile.am | 2 +-
 libsanitizer/sanitizer_common/Makefile.in | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libsanitizer/sanitizer_common/Makefile.am 
b/libsanitizer/sanitizer_common/Makefile.am
index 02afe65620a2..9ed6ef88775a 100644
--- a/libsanitizer/sanitizer_common/Makefile.am
+++ b/libsanitizer/sanitizer_common/Makefile.am
@@ -3,7 +3,7 @@ AM_CPPFLAGS = -I $(top_srcdir)/include -I $(top_srcdir) 
-isystem $(top_srcdir)/i
 # May be used by toolexeclibdir.
 gcc_version := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER)
 
-DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS @RPC_DEFS@
+DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS @RPC_DEFS@ @AS_SYM_ASSIGN_DEFS@
 AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic 
-Wno-long-long  -fPIC -fno-builtin -fno-exceptions -fno-rtti 
-fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros
 AM_CXXFLAGS += $(LIBSTDCXX_RAW_CXX_CXXFLAGS)
 AM_CXXFLAGS += -std=gnu++14
diff --git a/libsanitizer/sanitizer_common/Makefile.in 
b/libsanitizer/sanitizer_common/Makefile.in
index 45141930f9fa..31fff8236fee 100644
--- a/libsanitizer/sanitizer_common/Makefile.in
+++ b/libsanitizer/sanitizer_common/Makefile.in
@@ -245,7 +245,7 @@ CXXCPP = @CXXCPP@
 CXXDEPMODE = @CXXDEPMODE@
 CXXFLAGS = @CXXFLAGS@
 CYGPATH_W = @CYGPATH_W@
-DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS @RPC_DEFS@
+DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS @RPC_DEFS@ @AS_SYM_ASSIGN_DEFS@
 DEPDIR = @DEPDIR@
 DSYMUTIL = @DSYMUTIL@
 DUMPBIN = @DUMPBIN@
-- 
2.40.1



Re: [PATCH] libsanitizer: Enable LSan and TSan for riscv64

2024-01-02 Thread Jeff Law




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


[PATCH] libsanitizer: Enable LSan and TSan for riscv64

2024-01-02 Thread Andreas Schwab
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
--- a/libsanitizer/configure.tgt
+++ b/libsanitizer/configure.tgt
@@ -72,6 +72,11 @@ case "${target}" in
   x86_64-*-solaris2.11* | i?86-*-solaris2.11*)
;;
   riscv64-*-linux*)
+   if test x$ac_cv_sizeof_void_p = x8; then
+   TSAN_SUPPORTED=yes
+   LSAN_SUPPORTED=yes
+   TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_riscv64.lo
+   fi
;;
   loongarch64-*-linux*)
;;
-- 
2.43.0


-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."


Re: [PATCH] libsanitizer: Check assembler support for symbol assignment [PR112563]

2023-11-28 Thread Jakub Jelinek
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 later we need only the changes to the imported files be in one
> >> commit, not others, because merge.sh will not revert the GCC owned changes,
> >> just the imported ones, and so that is what should be reapplied.
> >> And, the preference of not using config.h is because we do it like that
> >> for other stuff already (exactly to minimize amount of local changes).
> >
> > ah, now I get it.  Will rework the patch accordingly.
> 
> here are both patches.
> 
> Bootstrapped on sparc-sun-solaris2.11 (as and gas) and
> i386-pc-solaris2.11 (as and gas).
> 
> Ok for trunk?

Yes, thanks.

Jakub



Re: [PATCH] libsanitizer: Check assembler support for symbol assignment [PR112563]

2023-11-28 Thread Rainer Orth
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, because merge.sh will not revert the GCC owned changes,
>> just the imported ones, and so that is what should be reapplied.
>> And, the preference of not using config.h is because we do it like that
>> for other stuff already (exactly to minimize amount of local changes).
>
> ah, now I get it.  Will rework the patch accordingly.

here are both patches.

Bootstrapped on sparc-sun-solaris2.11 (as and gas) and
i386-pc-solaris2.11 (as and gas).

Ok for trunk?

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


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.
* asan/Makefile.am (DEFS): Add @AS_SYM_ASSIGN_DEFS@.
* Makefile.in, asan/Makefile.in, hwasan/Makefile.in,
interception/Makefile.in, libbacktrace/Makefile.in,
lsan/Makefile.in, sanitizer_common/Makefile.in, tsan/Makefile.in,
ubsan/Makefile.in: Regenerate.

libsanitizer:
PR libsanitizer/112563
* sanitizer_common/sanitizer_redefine_builtins.h: Check
HAVE_AS_SYM_ASSIGN.

# HG changeset patch
# Parent  1f757467f1bed35373c55b65cde4f9b0506172f5
libsanitizer: Check assembler support for symbol assignment [PR112563]

diff --git a/libsanitizer/asan/Makefile.am b/libsanitizer/asan/Makefile.am
--- a/libsanitizer/asan/Makefile.am
+++ b/libsanitizer/asan/Makefile.am
@@ -3,7 +3,7 @@ AM_CPPFLAGS = -I $(top_srcdir)/include -
 # May be used by toolexeclibdir.
 gcc_version := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER)
 
-DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DASAN_HAS_EXCEPTIONS=1 -DASAN_NEEDS_SEGV=1 -DCAN_SANITIZE_UB=0 -DASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION=0
+DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DASAN_HAS_EXCEPTIONS=1 -DASAN_NEEDS_SEGV=1 -DCAN_SANITIZE_UB=0 -DASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION=0 @AS_SYM_ASSIGN_DEFS@
 if USING_MAC_INTERPOSE
 DEFS += -DMAC_INTERPOSE_FUNCTIONS -DMISSING_BLOCKS_SUPPORT
 endif
diff --git a/libsanitizer/configure.ac b/libsanitizer/configure.ac
--- a/libsanitizer/configure.ac
+++ b/libsanitizer/configure.ac
@@ -214,6 +214,19 @@ if test "$libsanitizer_cv_sys_atomic" = 
 	[Define to 1 if you have the __atomic functions])
 fi
 
+# Check if assembler supports symbol assignment.
+AC_CACHE_CHECK([assembler symbol assignment],
+[libsanitizer_cv_as_sym_assign],
+[AC_COMPILE_IFELSE(
+  [AC_LANG_PROGRAM([],
+		   [asm("a = b");])],
+  [libsanitizer_cv_as_sym_assign=yes],
+  [libsanitizer_cv_as_sym_assign=no])])
+if test "$libsanitizer_cv_as_sym_assign" = "yes"; then
+  as_sym_assign_defs=-DHAVE_AS_SYM_ASSIGN=1
+fi
+AC_SUBST(AS_SYM_ASSIGN_DEFS, [$as_sym_assign_defs])
+
 # The library needs to be able to read the executable itself.  Compile
 # a file to determine the executable format.  The awk script
 # filetype.awk prints out the file type.
# HG changeset patch
# Parent  60ba51b7bcf476549e3d8165b7c90ec0a3cf0979
libsanitizer: Require assembler support for sanitizer_redefine_builtins.h [PR112563]

diff --git a/libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h b/libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h
--- a/libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h
+++ b/libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h
@@ -15,7 +15,7 @@
 #define SANITIZER_REDEFINE_BUILTINS_H
 
 // The asm hack only works with GCC and Clang.
-#if !defined(_WIN32)
+#if !defined(_WIN32) && defined(HAVE_AS_SYM_ASSIGN)
 
 asm("memcpy = __sanitizer_internal_memcpy");
 asm("memmove = __sanitizer_internal_memmove");
@@ -50,7 +50,7 @@ using vector = Define_SANITIZER_COMMON_N
 }  // namespace std
 
 #  endif  // __cpluplus
-#endif// !_WIN32
+#endif// !_WIN32 && HAVE_AS_SYM_ASSIGN
 
 #  endif  // SANITIZER_REDEFINE_BUILTINS_H
 #endif// SANITIZER_COMMON_NO_REDEFINE_BUILTINS


Re: [PATCH] libsanitizer: Check assembler support for symbol assignment [PR112563]

2023-11-27 Thread Rainer Orth
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, because merge.sh will not revert the GCC owned changes,
> just the imported ones, and so that is what should be reapplied.
> And, the preference of not using config.h is because we do it like that
> for other stuff already (exactly to minimize amount of local changes).

ah, now I get it.  Will rework the patch accordingly.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [PATCH] libsanitizer: Check assembler support for symbol assignment [PR112563]

2023-11-27 Thread Jakub Jelinek
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, config.h.in: Regenerate.
> >>* sanitizer_common/sanitizer_redefine_builtins.h: Include config.h.
> >>Check HAVE_AS_SYM_ASSIGN.
> >
> > Can you please
> > 1) split it into 2 patches, one touching config* which is owned by GCC (and
> >Makefiles, see later), one just 
> > sanitizer_common/sanitizer_redefine_builtins.h
> > 2) avoid using config.h in, instead use AC_SUBST and add 
> > @HAVE_AS_SYM_ASSIGN@
> >to Makefile.am's DEFS where needed (either expanding to nothing or
> >-DHAVE_AS_SYM_ASSIGN=1)?  The reason is to minimize changes to imported
> >sources
> >
> > Once the sanitizer_common/sanitizer_redefine_builtins.h change (just
> > the && defined(HAVE_AS_SYM_ASSIGN) addition) patch is committed and pushed
> > upstream, add its commit has LOCAL_PATCHES.
> 
> 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, because merge.sh will not revert the GCC owned changes,
just the imported ones, and so that is what should be reapplied.
And, the preference of not using config.h is because we do it like that
for other stuff already (exactly to minimize amount of local changes).

> If we go (or at least try) this upstream route, should I wait for
> approval there and than commit both parts to GCC, keeping it in my local
> tree until then?
> 
> > Note, your ChangeLog entry was pretending config.h include has been added
> > to one header, but it went to a different one instead.
> 
> Drats, that's what you get for starting one way and adjusting later ;-)

Jakub



Re: [PATCH] libsanitizer: Check assembler support for symbol assignment [PR112563]

2023-11-27 Thread Rainer Orth
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_builtins.h: Include config.h.
>>  Check HAVE_AS_SYM_ASSIGN.
>
> Can you please
> 1) split it into 2 patches, one touching config* which is owned by GCC (and
>Makefiles, see later), one just 
> sanitizer_common/sanitizer_redefine_builtins.h
> 2) avoid using config.h in, instead use AC_SUBST and add @HAVE_AS_SYM_ASSIGN@
>to Makefile.am's DEFS where needed (either expanding to nothing or
>-DHAVE_AS_SYM_ASSIGN=1)?  The reason is to minimize changes to imported
>sources
>
> Once the sanitizer_common/sanitizer_redefine_builtins.h change (just
> the && defined(HAVE_AS_SYM_ASSIGN) addition) patch is committed and pushed
> upstream, add its commit has LOCAL_PATCHES.

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.

If we go (or at least try) this upstream route, should I wait for
approval there and than commit both parts to GCC, keeping it in my local
tree until then?

> Note, your ChangeLog entry was pretending config.h include has been added
> to one header, but it went to a different one instead.

Drats, that's what you get for starting one way and adjusting later ;-)

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [PATCH] libsanitizer: Check assembler support for symbol assignment [PR112563]

2023-11-27 Thread Jakub Jelinek
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: ".libs/sanitizer_errno.s", line 4247: error: symbol 
> "__sanitizer_internal_memcpy" is used but not defined
> /usr/ccs/bin/as: ".libs/sanitizer_errno.s", line 4247: error: symbol 
> "__sanitizer_internal_memmove" is used but not defined
> 
> Since none of the alternatives considered in the PR worked out, this
> patch checks if the assembler does support symbol assignment, disabling
> the code otherwise.  This returns the code to the way it was up to LLVM 16.
> 
> Bootstrapped without regressions on sparc-sun-solaris2.11 (as and gas),
> i386-pc-solaris2.11, x86_64-pc-linux-gnu, and x86_64-apple-darwin21.6.0.
> 
> Ok for trunk?
> 
>   Rainer
> 
> -- 
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
> 
> 
> 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_builtins.h: Include config.h.
>   Check HAVE_AS_SYM_ASSIGN.

Can you please
1) split it into 2 patches, one touching config* which is owned by GCC (and
   Makefiles, see later), one just 
sanitizer_common/sanitizer_redefine_builtins.h
2) avoid using config.h in, instead use AC_SUBST and add @HAVE_AS_SYM_ASSIGN@
   to Makefile.am's DEFS where needed (either expanding to nothing or
   -DHAVE_AS_SYM_ASSIGN=1)?  The reason is to minimize changes to imported
   sources

Once the sanitizer_common/sanitizer_redefine_builtins.h change (just
the && defined(HAVE_AS_SYM_ASSIGN) addition) patch is committed and pushed
upstream, add its commit has LOCAL_PATCHES.

Thanks.

Note, your ChangeLog entry was pretending config.h include has been added
to one header, but it went to a different one instead.

> # HG changeset patch
> # Parent  1f757467f1bed35373c55b65cde4f9b0506172f5
> libsanitizer: Require assembler support for sanitizer_redefine_builtins.h 
> [PR112563]
> 
> diff --git a/libsanitizer/configure.ac b/libsanitizer/configure.ac
> --- a/libsanitizer/configure.ac
> +++ b/libsanitizer/configure.ac
> @@ -214,6 +214,19 @@ if test "$libsanitizer_cv_sys_atomic" = 
>   [Define to 1 if you have the __atomic functions])
>  fi
>  
> +# Check if assembler supports symbol assignment.
> +AC_CACHE_CHECK([assembler symbol assignment],
> +[libsanitizer_cv_as_sym_assign],
> +[AC_COMPILE_IFELSE(
> +  [AC_LANG_PROGRAM([],
> +[asm("a = b");])],
> +  [libsanitizer_cv_as_sym_assign=yes],
> +  [libsanitizer_cv_as_sym_assign=no])])
> +if test "$libsanitizer_cv_as_sym_assign" = "yes"; then
> +  AC_DEFINE([HAVE_AS_SYM_ASSIGN], 1,
> + [Define to 1 if assembler supports symbol assignment])
> +fi
> +
>  # The library needs to be able to read the executable itself.  Compile
>  # a file to determine the executable format.  The awk script
>  # filetype.awk prints out the file type.
> diff --git a/libsanitizer/sanitizer_common/sanitizer_internal_defs.h 
> b/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
> --- a/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
> +++ b/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
> @@ -12,6 +12,7 @@
>  #ifndef SANITIZER_DEFS_H
>  #define SANITIZER_DEFS_H
>  
> +#include "config.h"
>  #include "sanitizer_platform.h"
>  #include "sanitizer_redefine_builtins.h"
>  
> diff --git a/libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h 
> b/libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h
> --- a/libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h
> +++ b/libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h
> @@ -15,7 +15,7 @@
>  #define SANITIZER_REDEFINE_BUILTINS_H
>  
>  // The asm hack only works with GCC and Clang.
> -#if !defined(_WIN32)
> +#if !defined(_WIN32) && defined(HAVE_AS_SYM_ASSIGN)
>  
>  asm("memcpy = __sanitizer_internal_memcpy");
>  asm("memmove = __sanitizer_internal_memmove");
> @@ -50,7 +50,7 @@ using vector = Define_SANITIZER_COMMON_N
>  }  // namespace std
>  
>  #  endif  // __cpluplus
> -#endif// !_WIN32
> +#endif// !_WIN32 && HAVE_AS_SYM_ASSIGN
>  
>  #  endif  // SANITIZER_REDEFINE_BUILTINS_H
>  #endif// SANITIZER_COMMON_NO_REDEFINE_BUILTINS


Jakub



[PATCH] libsanitizer: Check assembler support for symbol assignment [PR112563]

2023-11-27 Thread Rainer Orth
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_internal_memcpy" is used but not defined
/usr/ccs/bin/as: ".libs/sanitizer_errno.s", line 4247: error: symbol 
"__sanitizer_internal_memmove" is used but not defined

Since none of the alternatives considered in the PR worked out, this
patch checks if the assembler does support symbol assignment, disabling
the code otherwise.  This returns the code to the way it was up to LLVM 16.

Bootstrapped without regressions on sparc-sun-solaris2.11 (as and gas),
i386-pc-solaris2.11, x86_64-pc-linux-gnu, and x86_64-apple-darwin21.6.0.

Ok for trunk?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


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_builtins.h: Include config.h.
Check HAVE_AS_SYM_ASSIGN.

# HG changeset patch
# Parent  1f757467f1bed35373c55b65cde4f9b0506172f5
libsanitizer: Require assembler support for sanitizer_redefine_builtins.h [PR112563]

diff --git a/libsanitizer/configure.ac b/libsanitizer/configure.ac
--- a/libsanitizer/configure.ac
+++ b/libsanitizer/configure.ac
@@ -214,6 +214,19 @@ if test "$libsanitizer_cv_sys_atomic" = 
 	[Define to 1 if you have the __atomic functions])
 fi
 
+# Check if assembler supports symbol assignment.
+AC_CACHE_CHECK([assembler symbol assignment],
+[libsanitizer_cv_as_sym_assign],
+[AC_COMPILE_IFELSE(
+  [AC_LANG_PROGRAM([],
+		   [asm("a = b");])],
+  [libsanitizer_cv_as_sym_assign=yes],
+  [libsanitizer_cv_as_sym_assign=no])])
+if test "$libsanitizer_cv_as_sym_assign" = "yes"; then
+  AC_DEFINE([HAVE_AS_SYM_ASSIGN], 1,
+  	[Define to 1 if assembler supports symbol assignment])
+fi
+
 # The library needs to be able to read the executable itself.  Compile
 # a file to determine the executable format.  The awk script
 # filetype.awk prints out the file type.
diff --git a/libsanitizer/sanitizer_common/sanitizer_internal_defs.h b/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
--- a/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
+++ b/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
@@ -12,6 +12,7 @@
 #ifndef SANITIZER_DEFS_H
 #define SANITIZER_DEFS_H
 
+#include "config.h"
 #include "sanitizer_platform.h"
 #include "sanitizer_redefine_builtins.h"
 
diff --git a/libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h b/libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h
--- a/libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h
+++ b/libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h
@@ -15,7 +15,7 @@
 #define SANITIZER_REDEFINE_BUILTINS_H
 
 // The asm hack only works with GCC and Clang.
-#if !defined(_WIN32)
+#if !defined(_WIN32) && defined(HAVE_AS_SYM_ASSIGN)
 
 asm("memcpy = __sanitizer_internal_memcpy");
 asm("memmove = __sanitizer_internal_memmove");
@@ -50,7 +50,7 @@ using vector = Define_SANITIZER_COMMON_N
 }  // namespace std
 
 #  endif  // __cpluplus
-#endif// !_WIN32
+#endif// !_WIN32 && HAVE_AS_SYM_ASSIGN
 
 #  endif  // SANITIZER_REDEFINE_BUILTINS_H
 #endif// SANITIZER_COMMON_NO_REDEFINE_BUILTINS


Re: Re: [PATCH] libsanitizer: adjust triplet pattern to allow loongarch64-linux* targets.

2023-11-16 Thread Yang Yujie
> ${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



Re: [PATCH] libsanitizer: adjust triplet pattern to allow loongarch64-linux* targets.

2023-11-16 Thread Jakub Jelinek
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
x86_64-pc-linux-gnu
loongarch64-unknown-linux-gnu
so I really don't see why you want to change it.

>  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.tgt
> +++ b/libsanitizer/configure.tgt
> @@ -73,7 +73,7 @@ case "${target}" in
>   ;;
>riscv64-*-linux*)
>   ;;
> -  loongarch64-*-linux*)
> +  loongarch64-*linux*)
>   ;;
>*)
>   UNSUPPORTED=1
> -- 
> 2.42.1

Jakub



[PATCH] libsanitizer: adjust triplet pattern to allow loongarch64-linux* targets.

2023-11-16 Thread Yang Yujie
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.tgt
+++ b/libsanitizer/configure.tgt
@@ -73,7 +73,7 @@ case "${target}" in
;;
   riscv64-*-linux*)
;;
-  loongarch64-*-linux*)
+  loongarch64-*linux*)
;;
   *)
UNSUPPORTED=1
-- 
2.42.1



Re: [PATCH] libsanitizer: Fix SPARC stacktraces

2023-08-07 Thread Jakub Jelinek via Gcc-patches
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/D156504)
> and I'd like to cherry-pick that patch.
> 
> Bootstrapped without regressions on sparc-sun-solaris2.11.
> 
> Ok for trunk and the gcc-13 branch?

Ok, thanks.

> 2023-07-27  Rainer Orth  
> 
>   libsanitizer:
>   * sanitizer_common/sanitizer_stacktrace_sparc.cpp,
>   sanitizer_common/sanitizer_unwind_linux_libcdep.cpp: Cherry-pick
>   llvm-project revision 679c076ae446af81eba81ce9b94203a273d4b88a.

Jakub



[PATCH] libsanitizer: Fix SPARC stacktraces

2023-08-07 Thread Rainer Orth
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 without regressions on sparc-sun-solaris2.11.

Ok for trunk and the gcc-13 branch?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2023-07-27  Rainer Orth  

libsanitizer:
* sanitizer_common/sanitizer_stacktrace_sparc.cpp,
sanitizer_common/sanitizer_unwind_linux_libcdep.cpp: Cherry-pick
llvm-project revision 679c076ae446af81eba81ce9b94203a273d4b88a.

# HG changeset patch
# Parent  cc61fd6b33c37b7a2a1415e0ed02f75dd8a21110
Fix SPARC stacktraces in sanitizers

diff --git a/libsanitizer/sanitizer_common/sanitizer_stacktrace_sparc.cpp b/libsanitizer/sanitizer_common/sanitizer_stacktrace_sparc.cpp
--- a/libsanitizer/sanitizer_common/sanitizer_stacktrace_sparc.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_stacktrace_sparc.cpp
@@ -30,13 +30,7 @@ void BufferedStackTrace::UnwindFast(uptr
   // TODO(yln): add arg sanity check for stack_top/stack_bottom
   CHECK_GE(max_depth, 2);
   const uptr kPageSize = GetPageSizeCached();
-#if defined(__GNUC__)
-  // __builtin_return_address returns the address of the call instruction
-  // on the SPARC and not the return address, so we need to compensate.
-  trace_buffer[0] = GetNextInstructionPc(pc);
-#else
   trace_buffer[0] = pc;
-#endif
   size = 1;
   if (stack_top < 4096) return;  // Sanity check for stack top.
   // Flush register windows to memory
diff --git a/libsanitizer/sanitizer_common/sanitizer_unwind_linux_libcdep.cpp b/libsanitizer/sanitizer_common/sanitizer_unwind_linux_libcdep.cpp
--- a/libsanitizer/sanitizer_common/sanitizer_unwind_linux_libcdep.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_unwind_linux_libcdep.cpp
@@ -139,13 +139,7 @@ void BufferedStackTrace::UnwindSlow(uptr
   if (to_pop == 0 && size > 1)
 to_pop = 1;
   PopStackFrames(to_pop);
-#if defined(__GNUC__) && defined(__sparc__)
-  // __builtin_return_address returns the address of the call instruction
-  // on the SPARC and not the return address, so we need to compensate.
-  trace_buffer[0] = GetNextInstructionPc(pc);
-#else
   trace_buffer[0] = pc;
-#endif
 }
 
 void BufferedStackTrace::UnwindSlow(uptr pc, void *context, u32 max_depth) {


Re: [PATCH] libsanitizer: cherry-pick commit 05551c658269 from upstream

2023-04-27 Thread H.J. Lu via Gcc-patches
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
>
> >
> > 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.h   | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git 
> > a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h 
> > b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> > index cfca7bdedbe..e6f298c26e1 100644
> > --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> > +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> > @@ -578,8 +578,13 @@ struct __sanitizer_sigset_t {
> >  #endif
> >
> >  struct __sanitizer_siginfo_pad {
> > +#if SANITIZER_X32
> > +  // x32 siginfo_t is aligned to 8 bytes.
> > +  u64 pad[128 / sizeof(u64)];
> > +#else
> >// Require uptr, because siginfo_t is always pointer-size aligned on 
> > Linux.
> >uptr pad[128 / sizeof(uptr)];
> > +#endif
> >  };
> >
> >  #if SANITIZER_LINUX
>


-- 
H.J.


Re: [PATCH] libsanitizer: cherry-pick commit 05551c658269 from upstream

2023-04-27 Thread Martin Liška
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
> 
>   * 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.h   | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h 
> b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> index cfca7bdedbe..e6f298c26e1 100644
> --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> @@ -578,8 +578,13 @@ struct __sanitizer_sigset_t {
>  #endif
>  
>  struct __sanitizer_siginfo_pad {
> +#if SANITIZER_X32
> +  // x32 siginfo_t is aligned to 8 bytes.
> +  u64 pad[128 / sizeof(u64)];
> +#else
>// Require uptr, because siginfo_t is always pointer-size aligned on Linux.
>uptr pad[128 / sizeof(uptr)];
> +#endif
>  };
>  
>  #if SANITIZER_LINUX



[PATCH] libsanitizer: cherry-pick commit 05551c658269 from upstream

2023-04-26 Thread H.J. Lu via Gcc-patches
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.h   | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h 
b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
index cfca7bdedbe..e6f298c26e1 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
@@ -578,8 +578,13 @@ struct __sanitizer_sigset_t {
 #endif
 
 struct __sanitizer_siginfo_pad {
+#if SANITIZER_X32
+  // x32 siginfo_t is aligned to 8 bytes.
+  u64 pad[128 / sizeof(u64)];
+#else
   // Require uptr, because siginfo_t is always pointer-size aligned on Linux.
   uptr pad[128 / sizeof(uptr)];
+#endif
 };
 
 #if SANITIZER_LINUX
-- 
2.40.0



Re: [PATCH] libsanitizer: cherry-pick commit 742bcbf685bc from upstream

2023-01-31 Thread Jakub Jelinek via Gcc-patches
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_sigsetjmp.
>   (__interceptor_sigsetjmp): Add a local alias,
>   .Linterceptor_sigsetjmp.

LGTM, thanks.

Jakub



[PATCH] libsanitizer: cherry-pick commit 742bcbf685bc from upstream

2023-01-31 Thread H.J. Lu via Gcc-patches
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,
.Linterceptor_sigsetjmp.
---
 libsanitizer/hwasan/hwasan_setjmp_x86_64.S | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libsanitizer/hwasan/hwasan_setjmp_x86_64.S 
b/libsanitizer/hwasan/hwasan_setjmp_x86_64.S
index 7566c1ea0a5..a5a3858d94d 100644
--- a/libsanitizer/hwasan/hwasan_setjmp_x86_64.S
+++ b/libsanitizer/hwasan/hwasan_setjmp_x86_64.S
@@ -37,13 +37,14 @@ __interceptor_setjmp:
   CFI_STARTPROC
   _CET_ENDBR
   xorl %esi, %esi
-  jmp  __interceptor_sigsetjmp
+  jmp  .Linterceptor_sigsetjmp
   CFI_ENDPROC
 ASM_SIZE(__interceptor_setjmp)
 
 .global __interceptor_sigsetjmp
 ASM_TYPE_FUNCTION(__interceptor_sigsetjmp)
 __interceptor_sigsetjmp:
+.Linterceptor_sigsetjmp:
   CFI_STARTPROC
   _CET_ENDBR
 
-- 
2.39.1



Re: [PATCH] libsanitizer: Add __interceptor_sigsetjmp_internal

2023-01-31 Thread Jakub Jelinek via Gcc-patches
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 sanitizers in LLVM, this should be filed in
https://reviews.llvm.org/differential/diff/create/
first (with diff -p -U1 or something similar I think they want there).
It can be then cherry-picked into GCC, or at least wait until there is
some agreement on what they want or whether they completely reject it
and we'd need to carry it as a GCC local patch (in that case it should
be in libsanitizer/LOCAL_PATCHES).

>   PR sanitizer/108106
>   * hwasan/hwasan_setjmp_x86_64.S (__interceptor_sigsetjmp): Add
>   an internal alias, __interceptor_sigsetjmp_internal.
> ---
>  libsanitizer/hwasan/hwasan_setjmp_x86_64.S | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libsanitizer/hwasan/hwasan_setjmp_x86_64.S 
> b/libsanitizer/hwasan/hwasan_setjmp_x86_64.S
> index 7566c1ea0a5..071dcdcf613 100644
> --- a/libsanitizer/hwasan/hwasan_setjmp_x86_64.S
> +++ b/libsanitizer/hwasan/hwasan_setjmp_x86_64.S
> @@ -37,13 +37,14 @@ __interceptor_setjmp:
>CFI_STARTPROC
>_CET_ENDBR
>xorl %esi, %esi
> -  jmp__interceptor_sigsetjmp
> +  jmp__interceptor_sigsetjmp_internal
>CFI_ENDPROC
>  ASM_SIZE(__interceptor_setjmp)
>  
>  .global __interceptor_sigsetjmp
>  ASM_TYPE_FUNCTION(__interceptor_sigsetjmp)
>  __interceptor_sigsetjmp:
> +__interceptor_sigsetjmp_internal:
>CFI_STARTPROC
>_CET_ENDBR
>  

Jakub



Re: [PATCH] libsanitizer: Fix asan SEGVs with gld on Solaris

2023-01-17 Thread Richard Biener via Gcc-patches
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 upstream at https://reviews.llvm.org/D141385.
>
> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11.
>
> Ok to cherry-pick into libsanitizer?

OK.

> Rainer
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
>
> 2023-01-17  Rainer Orth  
>
> libsanitizer:
> * sanitizer_common/sanitizer_platform_interceptors.h: Cherry-pick
> llvm-project revision 951cf656b2faaf6fc0baa867293c0cb0ab131951.
>


[PATCH] libsanitizer: Fix asan SEGVs with gld on Solaris

2023-01-17 Thread Rainer Orth
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-solaris2.11 and sparc-sun-solaris2.11.

Ok to cherry-pick into libsanitizer?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2023-01-17  Rainer Orth  

libsanitizer:
* sanitizer_common/sanitizer_platform_interceptors.h: Cherry-pick
llvm-project revision 951cf656b2faaf6fc0baa867293c0cb0ab131951.

# HG changeset patch
# Parent  5c31a29beaaa8ed8a5a0dd7a6c11062a0a208c3a
libsanitizer: Don't intercept __tls_get_addr on Solaris

diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_interceptors.h b/libsanitizer/sanitizer_common/sanitizer_platform_interceptors.h
--- a/libsanitizer/sanitizer_common/sanitizer_platform_interceptors.h
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_interceptors.h
@@ -405,7 +405,7 @@
   (SI_FREEBSD || SI_NETBSD || SI_GLIBC || SI_SOLARIS)
 
 #define SANITIZER_INTERCEPT_TLS_GET_ADDR \
-  (SI_FREEBSD || SI_NETBSD || SI_LINUX_NOT_ANDROID || SI_SOLARIS)
+  (SI_FREEBSD || SI_NETBSD || SI_LINUX_NOT_ANDROID)
 
 #define SANITIZER_INTERCEPT_LISTXATTR SI_LINUX
 #define SANITIZER_INTERCEPT_GETXATTR SI_LINUX


Re: [PATCH] libsanitizer/mips: always build with largefile support

2023-01-11 Thread YunQiang Su
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_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216);
> > in sanitizer_platform_limits_posix.h.
> >
> > To keep sync with LLVM and to make the code simple, we use the
> > largefile options always.
> >
> > libsanitizer/
> >   * configure.ac: set -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> > always for mips*.
> >   * configure: Regenerate.
>
> Hm, yes, that might be the most pragmatic way to solve the mips
> stat-size issue...  But shouldn't then largefile-options also be
> forced when libsanitizer is *used*?  IOW, mips*-linux
> gcc-options be tweaked to include -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64 conditional on sanitizer-options?
>

Sound a good idea...
While I am worrying about some application may fail to build or
trigger some other problems.

> brgds, H-P


Re: [PATCH] libsanitizer/mips: always build with largefile support

2023-01-10 Thread Hans-Peter Nilsson
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 sanitizer_platform_limits_posix.h.
> 
> To keep sync with LLVM and to make the code simple, we use the
> largefile options always.
> 
> libsanitizer/
>   * configure.ac: set -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> always for mips*.
>   * configure: Regenerate.

Hm, yes, that might be the most pragmatic way to solve the mips
stat-size issue...  But shouldn't then largefile-options also be 
forced when libsanitizer is *used*?  IOW, mips*-linux 
gcc-options be tweaked to include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 conditional on sanitizer-options?

brgds, H-P


[PATCH] libsanitizer/mips: always build with largefile support

2023-01-06 Thread YunQiang Su
-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 with LLVM and to make the code simple, we use the
largefile options always.

libsanitizer/
* configure.ac: set -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
  always for mips*.
* configure: Regenerate.
---
 libsanitizer/configure| 13 ++---
 libsanitizer/configure.ac | 12 ++--
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/libsanitizer/configure b/libsanitizer/configure
index d3de3dbba51..d4ee0fac3e7 100755
--- a/libsanitizer/configure
+++ b/libsanitizer/configure
@@ -17045,9 +17045,16 @@ else
 $as_echo "no" >&6; }
 fi
 
-EXTRA_CFLAGS="$EXTRA_CFLAGS $CET_FLAGS"
-EXTRA_CXXFLAGS="$EXTRA_CXXFLAGS $CET_FLAGS"
-EXTRA_ASFLAGS=$CET_FLAGS
+# Always set -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 to sync with LLVM,
+# and keep struct *stat* have the same size.
+case "${host}" in
+  mips*-*) FILE64_FLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" ;;
+  *) FILE64_FLAGS="" ;;
+esac
+
+EXTRA_CFLAGS="$EXTRA_CFLAGS $CET_FLAGS $FILE64_FLAGS"
+EXTRA_CXXFLAGS="$EXTRA_CXXFLAGS $CET_FLAGS $FILE64_FLAGS"
+EXTRA_ASFLAGS="$CET_FLAGS $FILE64_FLAGS"
 
 
 
diff --git a/libsanitizer/configure.ac b/libsanitizer/configure.ac
index ad49f29db7e..04cd8910ed6 100644
--- a/libsanitizer/configure.ac
+++ b/libsanitizer/configure.ac
@@ -416,8 +416,16 @@ GCC_BASE_VER
 
 # Add CET specific flags if Intel CET is enabled.
 GCC_CET_FLAGS(CET_FLAGS)
-EXTRA_CFLAGS="$EXTRA_CFLAGS $CET_FLAGS"
-EXTRA_CXXFLAGS="$EXTRA_CXXFLAGS $CET_FLAGS"
+
+# Always set -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 to sync with LLVM,
+# and keep struct *stat* have the same size.
+case "${host}" in
+  mips*-*) FILE64_FLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" ;;
+  *) FILE64_FLAGS="" ;;
+esac
+
+EXTRA_CFLAGS="$EXTRA_CFLAGS $CET_FLAGS $FILE64_FLAGS"
+EXTRA_CXXFLAGS="$EXTRA_CXXFLAGS $CET_FLAGS $FILE64_FLAGS"
 EXTRA_ASFLAGS=$CET_FLAGS
 AC_SUBST(EXTRA_ASFLAGS)
 AC_SUBST(EXTRA_CFLAGS)
-- 
2.30.2



[PATCH] libsanitizer: Add __interceptor_sigsetjmp_internal

2022-12-16 Thread H.J. Lu via Gcc-patches
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.
---
 libsanitizer/hwasan/hwasan_setjmp_x86_64.S | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libsanitizer/hwasan/hwasan_setjmp_x86_64.S 
b/libsanitizer/hwasan/hwasan_setjmp_x86_64.S
index 7566c1ea0a5..071dcdcf613 100644
--- a/libsanitizer/hwasan/hwasan_setjmp_x86_64.S
+++ b/libsanitizer/hwasan/hwasan_setjmp_x86_64.S
@@ -37,13 +37,14 @@ __interceptor_setjmp:
   CFI_STARTPROC
   _CET_ENDBR
   xorl %esi, %esi
-  jmp  __interceptor_sigsetjmp
+  jmp  __interceptor_sigsetjmp_internal
   CFI_ENDPROC
 ASM_SIZE(__interceptor_setjmp)
 
 .global __interceptor_sigsetjmp
 ASM_TYPE_FUNCTION(__interceptor_sigsetjmp)
 __interceptor_sigsetjmp:
+__interceptor_sigsetjmp_internal:
   CFI_STARTPROC
   _CET_ENDBR
 
-- 
2.38.1



Re: [PATCH] libsanitizer: Avoid implicit function declaration in configure test

2022-10-18 Thread Jakub Jelinek via Gcc-patches
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.

>   Include  for syscall prototype.
>   * configure: Regenerate.

Otherwise LGTM, thanks.

> --- a/libsanitizer/configure.ac
> +++ b/libsanitizer/configure.ac
> @@ -161,7 +161,8 @@ case "$target" in
>*-*-linux*)
>  # Some old Linux distributions miss required syscalls.
>  sanitizer_supported=no
> -AC_TRY_COMPILE([#include ],[
> +AC_TRY_COMPILE([#include 
> +#include ],[
>syscall (__NR_gettid);
>syscall (__NR_futex);
>syscall (__NR_exit_group);
> 
> base-commit: acdb24166d13d87c374e578d2ad5d58249171930

Jakub



[PATCH] libsanitizer: Avoid implicit function declaration in configure test

2022-10-18 Thread Florian Weimer via Gcc-patches
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/libsanitizer/configure b/libsanitizer/configure
index 3a0c47513e7..cb99faf6100 100755
--- a/libsanitizer/configure
+++ b/libsanitizer/configure
@@ -12383,7 +12383,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 12386 "configure"
+#line 12398 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -12489,7 +12489,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 12492 "configure"
+#line 12504 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -16072,6 +16072,7 @@ case "$target" in
 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 #include 
+#include 
 int
 main ()
 {
diff --git a/libsanitizer/configure.ac b/libsanitizer/configure.ac
index 7f1ef3979c4..ad49f29db7e 100644
--- a/libsanitizer/configure.ac
+++ b/libsanitizer/configure.ac
@@ -161,7 +161,8 @@ case "$target" in
   *-*-linux*)
 # Some old Linux distributions miss required syscalls.
 sanitizer_supported=no
-AC_TRY_COMPILE([#include ],[
+AC_TRY_COMPILE([#include 
+#include ],[
   syscall (__NR_gettid);
   syscall (__NR_futex);
   syscall (__NR_exit_group);

base-commit: acdb24166d13d87c374e578d2ad5d58249171930



Re: [PATCH] libsanitizer: enable libubsan and libasan for loongarch64-*-linux*

2022-08-31 Thread Lulu Cheng

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.exp tests.

libsanitizer/ChangeLog:

* configure.tgt: Allow loongarch64-*-linux*.
---
  libsanitizer/configure.tgt | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index fb89df4935c..87d8a2c3820 100644
--- a/libsanitizer/configure.tgt
+++ b/libsanitizer/configure.tgt
@@ -72,6 +72,8 @@ case "${target}" in
;;
riscv64-*-linux*)
;;
+  loongarch64-*-linux*)
+   ;;
*)
UNSUPPORTED=1
;;




[PATCH] libsanitizer: enable libubsan and libasan for loongarch64-*-linux*

2022-08-30 Thread Xi Ruoyao via Gcc-patches
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:

* configure.tgt: Allow loongarch64-*-linux*.
---
 libsanitizer/configure.tgt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index fb89df4935c..87d8a2c3820 100644
--- a/libsanitizer/configure.tgt
+++ b/libsanitizer/configure.tgt
@@ -72,6 +72,8 @@ case "${target}" in
;;
   riscv64-*-linux*)
;;
+  loongarch64-*-linux*)
+   ;;
   *)
UNSUPPORTED=1
;;
-- 
2.37.2



Re: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from upstream

2022-07-31 Thread Martin Liška
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


Re: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from upstream

2022-07-29 Thread Dimitrije Milosevic
Thanks Martin! I'm sending out the output from git format-patch as an 
attachment to this email.


From: Martin Liška 
Sent: Thursday, July 28, 2022 3:48 PM
To: Dimitrije Milosevic ; 
gcc-patches@gcc.gnu.org 
Cc: ma...@embecosm.com ; Djordje Todorovic 
; jos...@codesourcery.com 

Subject: 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 email has a weird format I can directly apply with git 
am.

Cheers,
MartinFrom 9d7646428bf36449cde380230bcc20fa835857dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dimitrije=20Milo=C5=A1evi=C4=87?=
 
Date: Fri, 29 Jul 2022 08:36:06 +0200
Subject: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from
 upstream

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/sanitizer_platform_limits_posix.h b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
index 89772a7e5c0..75c6cc7f285 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
@@ -81,9 +81,10 @@ const unsigned struct_kernel_stat64_sz = 104;
 const unsigned struct_kernel_stat_sz = 144;
 const unsigned struct_kernel_stat64_sz = 104;
 #elif defined(__mips__)
-const unsigned struct_kernel_stat_sz = SANITIZER_ANDROID
-   ? FIRST_32_SECOND_64(104, 128)
-   : FIRST_32_SECOND_64(144, 216);
+const unsigned struct_kernel_stat_sz =
+SANITIZER_ANDROID
+? FIRST_32_SECOND_64(104, 128)
+: FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216);
 const unsigned struct_kernel_stat64_sz = 104;
 #elif defined(__s390__) && !defined(__s390x__)
 const unsigned struct_kernel_stat_sz = 64;
-- 
2.25.1



Re: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from upstream

2022-07-28 Thread Martin Liška
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


Re: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from upstream

2022-07-28 Thread Dimitrije Milosevic
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 
 
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/sanitizer_platform_limits_posix.h 
b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
index 89772a7e5c0..75c6cc7f285 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
@@ -81,9 +81,10 @@ const unsigned struct_kernel_stat64_sz = 104;
 const unsigned struct_kernel_stat_sz = 144;
 const unsigned struct_kernel_stat64_sz = 104;
 #elif defined(__mips__)
-const unsigned struct_kernel_stat_sz = SANITIZER_ANDROID
-   ? FIRST_32_SECOND_64(104, 128)
-   : FIRST_32_SECOND_64(144, 216);
+const unsigned struct_kernel_stat_sz =
+    SANITIZER_ANDROID
+    ? FIRST_32_SECOND_64(104, 128)
+    : FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216);
 const unsigned struct_kernel_stat64_sz = 104;
 #elif defined(__s390__) && !defined(__s390x__)
 const unsigned struct_kernel_stat_sz = 64;
-- 
2.25.1

Re: PING: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from upstream

2022-07-27 Thread Richard Sandiford via Gcc-patches
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 being a MIPS
maintainer over eight years ago and Matthew moved on to other things
several years ago as well.  The port has been unmaintained for a long
time now.

For a while I tried to be practical and approve trivial patches, even
though working for an IP company makes that somewhat awkward from a
conflict-of-interest perspective.  But it's been so long now since
I worked on MIPS that the technical side is becoming a problem too.

Thanks,
Richard


Re: PING: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from upstream

2022-07-27 Thread Dimitrije Milosevic
> 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.


From: Xi Ruoyao 
Sent: Wednesday, July 27, 2022 8:43 AM
To: Dimitrije Milosevic ; 
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 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
better.

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: PING: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from upstream

2022-07-27 Thread Xi Ruoyao via Gcc-patches
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
better.

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


PING: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from upstream

2022-07-27 Thread Dimitrije Milosevic
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 from 
upstream 
 
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/sanitizer_platform_limits_posix.h 
b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
index 89772a7e5c0..75c6cc7f285 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
@@ -81,9 +81,10 @@ const unsigned struct_kernel_stat64_sz = 104;
 const unsigned struct_kernel_stat_sz = 144;
 const unsigned struct_kernel_stat64_sz = 104;
 #elif defined(__mips__)
-const unsigned struct_kernel_stat_sz = SANITIZER_ANDROID
-   ? FIRST_32_SECOND_64(104, 128)
-   : FIRST_32_SECOND_64(144, 216);
+const unsigned struct_kernel_stat_sz =
+    SANITIZER_ANDROID
+    ? FIRST_32_SECOND_64(104, 128)
+    : FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216);
 const unsigned struct_kernel_stat64_sz = 104;
 #elif defined(__s390__) && !defined(__s390x__)
 const unsigned struct_kernel_stat_sz = 64;
-- 
2.25.1

PING: [PATCH] libsanitizer: don't enable for MIPS Linux without GNU libc [PR 106136]

2022-07-25 Thread Xi Ruoyao via Gcc-patches
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 now.  If someone really
> cares
> about those alternative libc implementations, please submit patch to
> LLVM project adding the support.
> 
> libsanitizer/ChangeLog
> 
> PR sanitizer/106136
> * configure.tgt: Change mips*-*-linux* to mips*-*-linux-gnu*
> because it fails to build with non-GNU libc.
> ---
>  libsanitizer/configure.tgt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
> index fb89df4935c..54b74b60e2f 100644
> --- a/libsanitizer/configure.tgt
> +++ b/libsanitizer/configure.tgt
> @@ -54,7 +54,7 @@ case "${target}" in
> ;;
>    arm*-*-linux*)
> ;;
> -  mips*-*-linux*)
> +  mips*-*-linux-gnu*)
> ;;
>    aarch64*-*-linux*)
> if test x$ac_cv_sizeof_void_p = x8; then

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


Re: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from upstream

2022-07-25 Thread Xi Ruoyao via Gcc-patches
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:

xry111@gcc230:~$ cat t.c
#include 
#include 

int main()
{
  printf("%d\n", sizeof(struct stat));
}
xry111@gcc230:~$ cc t.c -mabi=32 && ./a.out 
144
xry111@gcc230:~$ cc t.c -mabi=n32 && ./a.out 
160
xry111@gcc230:~$ cc t.c -mabi=64 && ./a.out 
216

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


[PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from upstream

2022-07-25 Thread Dimitrije Milosevic
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/sanitizer_platform_limits_posix.h 
b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
index 89772a7e5c0..75c6cc7f285 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
@@ -81,9 +81,10 @@ const unsigned struct_kernel_stat64_sz = 104;
 const unsigned struct_kernel_stat_sz = 144;
 const unsigned struct_kernel_stat64_sz = 104;
 #elif defined(__mips__)
-const unsigned struct_kernel_stat_sz = SANITIZER_ANDROID
-   ? FIRST_32_SECOND_64(104, 128)
-   : FIRST_32_SECOND_64(144, 216);
+const unsigned struct_kernel_stat_sz =
+SANITIZER_ANDROID
+? FIRST_32_SECOND_64(104, 128)
+: FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216);
 const unsigned struct_kernel_stat64_sz = 104;
 #elif defined(__s390__) && !defined(__s390x__)
 const unsigned struct_kernel_stat_sz = 64;
-- 
2.25.1

Re: [PATCH] libsanitizer: Fix Solaris 11.3 compilation [PR105531]

2022-07-22 Thread Richard Biener via Gcc-patches
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.org/D120059
>
> I'd like to cherry-pick it into libsanitizer, too.
>
> Bootstrapped without regressions on sparc-sun-solaris2.11,
> i386-pc-solaris2.11 (both Solaris 11.3 and 11.4), and
> x86_64-pc-linux-gnu.
>
> Ok for trunk?

OK.

> Rainer
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
>
> 2022-07-21  Rainer Orth  
>
> libsanitizer:
> PR sanitizer/105531
> * libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp,
> libsanitizer/sanitizer_common/sanitizer_solaris.h:: Cherry-pick
> llvm-project revision 3776db9a4fd2080d23d6a5f52e405eea44558761.
>


[PATCH] libsanitizer: Fix Solaris 11.3 compilation [PR105531]

2022-07-22 Thread Rainer Orth
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.

Bootstrapped without regressions on sparc-sun-solaris2.11,
i386-pc-solaris2.11 (both Solaris 11.3 and 11.4), and
x86_64-pc-linux-gnu.

Ok for trunk?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2022-07-21  Rainer Orth  

libsanitizer:
PR sanitizer/105531
* libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp,
libsanitizer/sanitizer_common/sanitizer_solaris.h:: Cherry-pick
llvm-project revision 3776db9a4fd2080d23d6a5f52e405eea44558761.

# HG changeset patch
# Parent  755774c20b0c4c41572195333c097be29d392b53
libsanitizer: Fix Solaris 11.3 compilation [PR105531]

diff --git a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
--- a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
@@ -27,6 +27,7 @@
 #include "sanitizer_linux.h"
 #include "sanitizer_placement_new.h"
 #include "sanitizer_procmaps.h"
+#include "sanitizer_solaris.h"
 
 #if SANITIZER_NETBSD
 #define _RTLD_SOURCE  // for __lwp_gettcb_fast() / __lwp_getprivate_fast()
@@ -62,6 +63,7 @@
 #endif
 
 #if SANITIZER_SOLARIS
+#include 
 #include 
 #include 
 #endif
@@ -350,19 +352,43 @@ static uptr TlsGetOffset(uptr ti_module,
 extern "C" void *__tls_get_addr(size_t *);
 #endif
 
+static size_t main_tls_modid;
+
 static int CollectStaticTlsBlocks(struct dl_phdr_info *info, size_t size,
   void *data) {
-  if (!info->dlpi_tls_modid)
+  size_t tls_modid;
+#if SANITIZER_SOLARIS
+  // dlpi_tls_modid is only available since Solaris 11.4 SRU 10.  Use
+  // dlinfo(RTLD_DI_LINKMAP) instead which works on all of Solaris 11.3,
+  // 11.4, and Illumos.  The tlsmodid of the executable was changed to 1 in
+  // 11.4 to match other implementations.
+  if (size >= offsetof(dl_phdr_info_test, dlpi_tls_modid))
+main_tls_modid = 1;
+  else
+main_tls_modid = 0;
+  g_use_dlpi_tls_data = 0;
+  Rt_map *map;
+  dlinfo(RTLD_SELF, RTLD_DI_LINKMAP, );
+  tls_modid = map->rt_tlsmodid;
+#else
+  main_tls_modid = 1;
+  tls_modid = info->dlpi_tls_modid;
+#endif
+
+  if (tls_modid < main_tls_modid)
 return 0;
-  uptr begin = (uptr)info->dlpi_tls_data;
+  uptr begin;
+#if !SANITIZER_SOLARIS
+  begin = (uptr)info->dlpi_tls_data;
+#endif
   if (!g_use_dlpi_tls_data) {
 // Call __tls_get_addr as a fallback. This forces TLS allocation on glibc
 // and FreeBSD.
 #ifdef __s390__
 begin = (uptr)__builtin_thread_pointer() +
-TlsGetOffset(info->dlpi_tls_modid, 0);
+TlsGetOffset(tls_modid, 0);
 #else
-size_t mod_and_off[2] = {info->dlpi_tls_modid, 0};
+size_t mod_and_off[2] = {tls_modid, 0};
 begin = (uptr)__tls_get_addr(mod_and_off);
 #endif
   }
@@ -370,7 +396,7 @@ static int CollectStaticTlsBlocks(struct
 if (info->dlpi_phdr[i].p_type == PT_TLS) {
   static_cast *>(data)->push_back(
   TlsBlock{begin, begin + info->dlpi_phdr[i].p_memsz,
-   info->dlpi_phdr[i].p_align, info->dlpi_tls_modid});
+   info->dlpi_phdr[i].p_align, tls_modid});
   break;
 }
   return 0;
@@ -382,11 +408,11 @@ static int CollectStaticTlsBlocks(struct
   dl_iterate_phdr(CollectStaticTlsBlocks, );
   uptr len = ranges.size();
   Sort(ranges.begin(), len);
-  // Find the range with tls_modid=1. For glibc, because libc.so uses PT_TLS,
-  // this module is guaranteed to exist and is one of the initially loaded
-  // modules.
+  // Find the range with tls_modid == main_tls_modid. For glibc, because
+  // libc.so uses PT_TLS, this module is guaranteed to exist and is one of
+  // the initially loaded modules.
   uptr one = 0;
-  while (one != len && ranges[one].tls_modid != 1) ++one;
+  while (one != len && ranges[one].tls_modid != main_tls_modid) ++one;
   if (one == len) {
 // This may happen with musl if no module uses PT_TLS.
 *addr = 0;
diff --git a/libsanitizer/sanitizer_common/sanitizer_solaris.h b/libsanitizer/sanitizer_common/sanitizer_solaris.h
new file mode 100644
--- /dev/null
+++ b/libsanitizer/sanitizer_common/sanitizer_solaris.h
@@ -0,0 +1,56 @@
+//===-- sanitizer_solaris.h -*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file is a part of Sanitizer runtime. It 

Re: [PATCH] libsanitizer: cherry-pick 9cf13067cb5088626ba7 from upstream

2022-07-21 Thread Martin Liška
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


Re: [PATCH] libsanitizer: cherry-pick 9cf13067cb5088626ba7 from upstream

2022-07-21 Thread Richard Biener via Gcc-patches
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 resolve fsconfig_command/mount_attr conflict with glibc 2.36
> ---
>  .../sanitizer_platform_limits_posix.cpp| 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git 
> a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp 
> b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp
> index 8ed3e92d270..97fd07acf9d 100644
> --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp
> +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp
> @@ -73,7 +73,9 @@
>  #include 
>  #include 
>  #include 
> +#if SANITIZER_ANDROID
>  #include 
> +#endif
>  #include 
>  #include 
>  #include 
> @@ -869,10 +871,10 @@ unsigned struct_ElfW_Phdr_sz = sizeof(Elf_Phdr);
>unsigned IOCTL_EVIOCGPROP = IOCTL_NOT_PRESENT;
>unsigned IOCTL_EVIOCSKEYCODE_V2 = IOCTL_NOT_PRESENT;
>  #endif
> -  unsigned IOCTL_FS_IOC_GETFLAGS = FS_IOC_GETFLAGS;
> -  unsigned IOCTL_FS_IOC_GETVERSION = FS_IOC_GETVERSION;
> -  unsigned IOCTL_FS_IOC_SETFLAGS = FS_IOC_SETFLAGS;
> -  unsigned IOCTL_FS_IOC_SETVERSION = FS_IOC_SETVERSION;
> +  unsigned IOCTL_FS_IOC_GETFLAGS = _IOR('f', 1, long);
> +  unsigned IOCTL_FS_IOC_GETVERSION = _IOR('v', 1, long);
> +  unsigned IOCTL_FS_IOC_SETFLAGS = _IOW('f', 2, long);
> +  unsigned IOCTL_FS_IOC_SETVERSION = _IOW('v', 2, long);
>unsigned IOCTL_GIO_CMAP = GIO_CMAP;
>unsigned IOCTL_GIO_FONT = GIO_FONT;
>unsigned IOCTL_GIO_UNIMAP = GIO_UNIMAP;
> --
> 2.36.1
>


[PATCH] libsanitizer: cherry-pick 9cf13067cb5088626ba7 from upstream

2022-07-11 Thread Martin Liška
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| 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp 
b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp
index 8ed3e92d270..97fd07acf9d 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp
@@ -73,7 +73,9 @@
 #include 
 #include 
 #include 
+#if SANITIZER_ANDROID
 #include 
+#endif
 #include 
 #include 
 #include 
@@ -869,10 +871,10 @@ unsigned struct_ElfW_Phdr_sz = sizeof(Elf_Phdr);
   unsigned IOCTL_EVIOCGPROP = IOCTL_NOT_PRESENT;
   unsigned IOCTL_EVIOCSKEYCODE_V2 = IOCTL_NOT_PRESENT;
 #endif
-  unsigned IOCTL_FS_IOC_GETFLAGS = FS_IOC_GETFLAGS;
-  unsigned IOCTL_FS_IOC_GETVERSION = FS_IOC_GETVERSION;
-  unsigned IOCTL_FS_IOC_SETFLAGS = FS_IOC_SETFLAGS;
-  unsigned IOCTL_FS_IOC_SETVERSION = FS_IOC_SETVERSION;
+  unsigned IOCTL_FS_IOC_GETFLAGS = _IOR('f', 1, long);
+  unsigned IOCTL_FS_IOC_GETVERSION = _IOR('v', 1, long);
+  unsigned IOCTL_FS_IOC_SETFLAGS = _IOW('f', 2, long);
+  unsigned IOCTL_FS_IOC_SETVERSION = _IOW('v', 2, long);
   unsigned IOCTL_GIO_CMAP = GIO_CMAP;
   unsigned IOCTL_GIO_FONT = GIO_FONT;
   unsigned IOCTL_GIO_UNIMAP = GIO_UNIMAP;
-- 
2.36.1



[PATCH] libsanitizer: Fix linkage errors for cross toolchains

2022-07-01 Thread Dimitrije Milosevic
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 -fsanitize=... 
gives a linkage error.
More information can be found here: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69839.

GCC, even when configured with -with-sysroot, by default, doesn't install 
libstdc++.so*
within the sysroot, as GCC's installation process isn't designed to help 
construct sysroot trees.
This has to be done manually. 
Furthermore, if we are using a multiarch/multilib configuration (mips-mti*, for 
example), 
we may not even want to install them within the sysroot.
Would love to hear your thoughts on this, as I'm not sure myself that this is 
the best solution.

gcc/ChangeLog:

* gcc.cc (LIBSAN_RPATH): New macro.
(LIBASAN_SPEC): Add LIBSAN_RPATH.
(LIBTSAN_SPEC): Likewise.
(LIBLSAN_SPEC): Likewise.
(LIBUBSAN_SPEC): Likewise.

libsanitizer/ChangeLog:

* Makefile.in: New Makefile variable.
* asan/Makefile.in: Likewise.
* configure: Regenerate.
* configure.ac: New config variable.
* hwasan/Makefile.in: New Makefile variable.
* interception/Makefile.in: Likewise.
* libbacktrace/Makefile.in: Likewise.
* libsanitizer.spec.in: New spec.
* lsan/Makefile.in: New Makefile variable.
* sanitizer_common/Makefile.in: Likewise.
* tsan/Makefile.in: Likewise.
* ubsan/Makefile.in: Likewise.

---

 gcc/gcc.cc| 20 
 libsanitizer/Makefile.in  |  1 +
 libsanitizer/asan/Makefile.in |  1 +
 libsanitizer/configure| 10 --
 libsanitizer/configure.ac |  7 +++
 libsanitizer/hwasan/Makefile.in   |  1 +
 libsanitizer/interception/Makefile.in |  1 +
 libsanitizer/libbacktrace/Makefile.in |  1 +
 libsanitizer/libsanitizer.spec.in |  2 ++
 libsanitizer/lsan/Makefile.in |  1 +
 libsanitizer/sanitizer_common/Makefile.in |  1 +
 libsanitizer/tsan/Makefile.in |  1 +
 libsanitizer/ubsan/Makefile.in|  1 +
 13 files changed, 38 insertions(+), 10 deletions(-)

diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 299e09c4f54..0d2d361b9a4 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -738,17 +738,21 @@ proper position among the other output files.  */
 #define STACK_SPLIT_SPEC " %{fsplit-stack: --wrap=pthread_create}"
 #endif
 
+#ifndef LIBSAN_RPATH
+#define LIBSAN_RPATH " %:include(libsanitizer.spec)%(link_libsan_rpath)"
+#endif
+
 #ifndef LIBASAN_SPEC
 #define STATIC_LIBASAN_LIBS \
   " %{static-libasan|static:%:include(libsanitizer.spec)%(link_libasan)}"
 #ifdef LIBASAN_EARLY_SPEC
-#define LIBASAN_SPEC STATIC_LIBASAN_LIBS
+#define LIBASAN_SPEC STATIC_LIBASAN_LIBS LIBSAN_RPATH
 #elif defined(HAVE_LD_STATIC_DYNAMIC)
 #define LIBASAN_SPEC "%{static-libasan:" LD_STATIC_OPTION \
 "} -lasan %{static-libasan:" LD_DYNAMIC_OPTION "}" \
 STATIC_LIBASAN_LIBS
 #else
-#define LIBASAN_SPEC "-lasan" STATIC_LIBASAN_LIBS
+#define LIBASAN_SPEC "-lasan" STATIC_LIBASAN_LIBS LIBSAN_RPATH
 #endif
 #endif
 
@@ -778,13 +782,13 @@ proper position among the other output files.  */
 #define STATIC_LIBTSAN_LIBS \
   " %{static-libtsan|static:%:include(libsanitizer.spec)%(link_libtsan)}"
 #ifdef LIBTSAN_EARLY_SPEC
-#define LIBTSAN_SPEC STATIC_LIBTSAN_LIBS
+#define LIBTSAN_SPEC STATIC_LIBTSAN_LIBS LIBSAN_RPATH
 #elif defined(HAVE_LD_STATIC_DYNAMIC)
 #define LIBTSAN_SPEC "%{static-libtsan:" LD_STATIC_OPTION \
 "} -ltsan %{static-libtsan:" LD_DYNAMIC_OPTION "}" \
 STATIC_LIBTSAN_LIBS
 #else
-#define LIBTSAN_SPEC "-ltsan" STATIC_LIBTSAN_LIBS
+#define LIBTSAN_SPEC "-ltsan" STATIC_LIBTSAN_LIBS LIBSAN_RPATH
 #endif
 #endif
 
@@ -796,13 +800,13 @@ proper position among the other output files.  */
 #define STATIC_LIBLSAN_LIBS \
   " %{static-liblsan|static:%:include(libsanitizer.spec)%(link_liblsan)}"
 #ifdef LIBLSAN_EARLY_SPEC
-#define LIBLSAN_SPEC STATIC_LIBLSAN_LIBS
+#define LIBLSAN_SPEC STATIC_LIBLSAN_LIBS LIBSAN_RPATH
 #elif defined(HAVE_LD_STATIC_DYNAMIC)
 #define LIBLSAN_SPEC "%{static-liblsan:" LD_STATIC_OPTION \
 "} -llsan %{static-liblsan:" LD_DYNAMIC_OPTION "}" \
 STATIC_LIBLSAN_LIBS
 #else
-#define LIBLSAN_SPEC "-llsan" STATIC_LIBLSAN_LIBS
+#define LIBLSAN_SPEC "-llsan" STATIC_LIBLSAN_LIBS LIBSAN_RPATH
 #endif
 #endif
 
@@ -816,9 +820,9 @@ proper position among the other output files.  */
 #ifdef HAVE_LD_STATIC_DYNAMIC
 #define LIBUBSAN_SPEC "%{static-libubsan:" LD_STATIC_OPTION \
 "} -lubsan %{static-libubsan:" 

Re: [PATCH] libsanitizer: Fix linkage errors for cross toolchains

2022-07-01 Thread Xi Ruoyao via Gcc-patches
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 libraries.
> This directory, however, is not in RPATH, so attempting to build a
> dynamically linked application with -fsanitize=... gives a linkage
> error.
> More information can be found here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69839.

Hmm... Is anyone really using a cross compiler without a sysroot?  PR
69839 is already closed as INVALID.  If you don't want to install GCC
runtime libraries into the sysroot (for example, for multiple GCC builds
using a shared sysroot), we have --enable-version-specific-runtime-libs
but unfortunately it's broken (PR 32415).

Please explain the actual use case and let us elaborate to see if there
is a better solution.

> gcc/ChangeLog:
>   * gcc.c (LIBSAN_RPATH): New macro.
>   (LIBASAN_SPEC): Add LIBSAN_RPATH.
>   (LIBUBSAN_SPEC): Likewise.
>  (LIBTSAN_SPEC): Likewise.
>  (LIBLSAN_SPEC): Likewise.
> 
> libsanitizer/ChangeLog:
>   * configure.ac (link_libsan_rpath): New config variable.
>   * libsanitizer.spec.in (link_libsan_rpath): New spec.
>   * configure (link_libsan_rpath): New config variable.
>   * Makefile.in (link_libsan_rpath): Define new Makefile
> variable.
>   * asan/Makefile.in: Likewise.
>   * interception/Makefile.in: Likewise.
>   * libbacktrace/Makefile.in: Likewise.
>   * lsan/Makefile.in: Likewise.
>   * sanitizer_common/Makefile.in: Likewise.
>   * tsan/Makefile.in: Likewise.
>   * ubsan/Makefile.in: Likewise.
>   * hwasan/Makefile.in: Likewise.
> 
> ---
> 
>  gcc/gcc.cc                                | 20 
>  libsanitizer/Makefile.in                  |  1 +
>  libsanitizer/asan/Makefile.in             |  1 +
>  libsanitizer/configure                    | 10 --
>  libsanitizer/configure.ac                 |  7 +++
>  libsanitizer/hwasan/Makefile.in           |  1 +
>  libsanitizer/interception/Makefile.in     |  1 +
>  libsanitizer/libbacktrace/Makefile.in     |  1 +
>  libsanitizer/libsanitizer.spec.in         |  2 ++
>  libsanitizer/lsan/Makefile.in             |  1 +
>  libsanitizer/sanitizer_common/Makefile.in |  1 +
>  libsanitizer/tsan/Makefile.in             |  1 +
>  libsanitizer/ubsan/Makefile.in            |  1 +
>  13 files changed, 38 insertions(+), 10 deletions(-)
> 
> 
> diff --git a/gcc/gcc.cc b/gcc/gcc.ccindex 299e09c4f54..37ff75f1ad5
> 100644
> --- a/gcc/gcc.cc
> +++ b/gcc/gcc.cc
> @@ -738,17 +738,21 @@ proper position among the other output files.
>  */
>  #define STACK_SPLIT_SPEC " %{fsplit-stack: --wrap=pthread_create}"
>  #endif
>  
> +#ifndef LIBSAN_RPATH
> +#define LIBSAN_RPATH "
> %:include(libsanitizer.spec)%(link_libsan_rpath)"
> +#endif
> +
>  #ifndef LIBASAN_SPEC
>  #define STATIC_LIBASAN_LIBS \
>    " %{static-
> libasan|static:%:include(libsanitizer.spec)%(link_libasan)}"
>  #ifdef LIBASAN_EARLY_SPEC
> -#define LIBASAN_SPEC STATIC_LIBASAN_LIBS
> +#define LIBASAN_SPEC STATIC_LIBASAN_LIBS LIBSAN_RPATH
>  #elif defined(HAVE_LD_STATIC_DYNAMIC)
>  #define LIBASAN_SPEC "%{static-libasan:" LD_STATIC_OPTION \
>                      "} -lasan %{static-libasan:" LD_DYNAMIC_OPTION
> "}" \
>                      STATIC_LIBASAN_LIBS
>  #else
> -#define LIBASAN_SPEC "-lasan" STATIC_LIBASAN_LIBS
> +#define LIBASAN_SPEC "-lasan" STATIC_LIBASAN_LIBS LIBSAN_RPATH
>  #endif
>  #endif
>  
> @@ -778,13 +782,13 @@ proper position among the other output files.
>  */
>  #define STATIC_LIBTSAN_LIBS \
>    " %{static-
> libtsan|static:%:include(libsanitizer.spec)%(link_libtsan)}"
>  #ifdef LIBTSAN_EARLY_SPEC
> -#define LIBTSAN_SPEC STATIC_LIBTSAN_LIBS
> +#define LIBTSAN_SPEC STATIC_LIBTSAN_LIBS LIBSAN_RPATH
>  #elif defined(HAVE_LD_STATIC_DYNAMIC)
>  #define LIBTSAN_SPEC "%{static-libtsan:" LD_STATIC_OPTION \
>                      "} -ltsan %{static-libtsan:" LD_DYNAMIC_OPTION
> "}" \
>                      STATIC_LIBTSAN_LIBS
>  #else
> -#define LIBTSAN_SPEC "-ltsan" STATIC_LIBTSAN_LIBS
> +#define LIBTSAN_SPEC "-ltsan" STATIC_LIBTSAN_LIBS LIBSAN_RPATH
>  #endif
>  #endif
>  
> @@ -793,7 +797,7 @@ proper position among the other output files.  */
>  #endif
>  
>  #ifndef LIBLSAN_SPEC
> -#define STATIC_LIBLSAN_LIBS \
> +#define STATIC_LIBLSAN_LIBS LIBSAN_RPATH \
>    " %{static-
> liblsan|static:%:include(libsanitizer.spec)%(link_liblsan)}"
>  #ifdef LIBLSAN_EARLY_SPEC
>  #define LIBLSAN_SPEC STATIC_LIBLSAN_LIBS
> @@ -802,7 +806,7 @@ proper position among the other output files.  */
>                      "} -llsan %{static-liblsan:" LD_DYNAMIC_OPTION
> "}" \
>                      STATIC_LIBLSAN_LIBS
>  #else
> -#define LIBLSAN_SPEC "-llsan" STATIC_LIBLSAN_LIBS
> +#define LIBLSAN_SPEC "-llsan" STATIC_LIBLSAN_LIBS LIBSAN_RPATH

[PATCH] libsanitizer: Fix linkage errors for cross toolchains

2022-07-01 Thread Dimitrije Milosevic
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 
-fsanitize=... gives a linkage error.
More information can be found here: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69839.


gcc/ChangeLog:
* gcc.c (LIBSAN_RPATH): New macro.
(LIBASAN_SPEC): Add LIBSAN_RPATH.
(LIBUBSAN_SPEC): Likewise.
 (LIBTSAN_SPEC): Likewise.
 (LIBLSAN_SPEC): Likewise.

libsanitizer/ChangeLog:
* configure.ac (link_libsan_rpath): New config variable.
* libsanitizer.spec.in (link_libsan_rpath): New spec.
* configure (link_libsan_rpath): New config variable.
* Makefile.in (link_libsan_rpath): Define new Makefile variable.
* asan/Makefile.in: Likewise.
* interception/Makefile.in: Likewise.
* libbacktrace/Makefile.in: Likewise.
* lsan/Makefile.in: Likewise.
* sanitizer_common/Makefile.in: Likewise.
* tsan/Makefile.in: Likewise.
* ubsan/Makefile.in: Likewise.
* hwasan/Makefile.in: Likewise.

---

 gcc/gcc.cc| 20 
 libsanitizer/Makefile.in  |  1 +
 libsanitizer/asan/Makefile.in |  1 +
 libsanitizer/configure| 10 --
 libsanitizer/configure.ac |  7 +++
 libsanitizer/hwasan/Makefile.in   |  1 +
 libsanitizer/interception/Makefile.in |  1 +
 libsanitizer/libbacktrace/Makefile.in |  1 +
 libsanitizer/libsanitizer.spec.in |  2 ++
 libsanitizer/lsan/Makefile.in |  1 +
 libsanitizer/sanitizer_common/Makefile.in |  1 +
 libsanitizer/tsan/Makefile.in |  1 +
 libsanitizer/ubsan/Makefile.in|  1 +
 13 files changed, 38 insertions(+), 10 deletions(-)


diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 299e09c4f54..37ff75f1ad5 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -738,17 +738,21 @@ proper position among the other output files.  */
 #define STACK_SPLIT_SPEC " %{fsplit-stack: --wrap=pthread_create}"
 #endif

+#ifndef LIBSAN_RPATH
+#define LIBSAN_RPATH " %:include(libsanitizer.spec)%(link_libsan_rpath)"
+#endif
+
 #ifndef LIBASAN_SPEC
 #define STATIC_LIBASAN_LIBS \
   " %{static-libasan|static:%:include(libsanitizer.spec)%(link_libasan)}"
 #ifdef LIBASAN_EARLY_SPEC
-#define LIBASAN_SPEC STATIC_LIBASAN_LIBS
+#define LIBASAN_SPEC STATIC_LIBASAN_LIBS LIBSAN_RPATH
 #elif defined(HAVE_LD_STATIC_DYNAMIC)
 #define LIBASAN_SPEC "%{static-libasan:" LD_STATIC_OPTION \
 "} -lasan %{static-libasan:" LD_DYNAMIC_OPTION "}" \
 STATIC_LIBASAN_LIBS
 #else
-#define LIBASAN_SPEC "-lasan" STATIC_LIBASAN_LIBS
+#define LIBASAN_SPEC "-lasan" STATIC_LIBASAN_LIBS LIBSAN_RPATH
 #endif
 #endif

@@ -778,13 +782,13 @@ proper position among the other output files.  */
 #define STATIC_LIBTSAN_LIBS \
   " %{static-libtsan|static:%:include(libsanitizer.spec)%(link_libtsan)}"
 #ifdef LIBTSAN_EARLY_SPEC
-#define LIBTSAN_SPEC STATIC_LIBTSAN_LIBS
+#define LIBTSAN_SPEC STATIC_LIBTSAN_LIBS LIBSAN_RPATH
 #elif defined(HAVE_LD_STATIC_DYNAMIC)
 #define LIBTSAN_SPEC "%{static-libtsan:" LD_STATIC_OPTION \
 "} -ltsan %{static-libtsan:" LD_DYNAMIC_OPTION "}" \
 STATIC_LIBTSAN_LIBS
 #else
-#define LIBTSAN_SPEC "-ltsan" STATIC_LIBTSAN_LIBS
+#define LIBTSAN_SPEC "-ltsan" STATIC_LIBTSAN_LIBS LIBSAN_RPATH
 #endif
 #endif

@@ -793,7 +797,7 @@ proper position among the other output files.  */
 #endif

 #ifndef LIBLSAN_SPEC
-#define STATIC_LIBLSAN_LIBS \
+#define STATIC_LIBLSAN_LIBS LIBSAN_RPATH \
   " %{static-liblsan|static:%:include(libsanitizer.spec)%(link_liblsan)}"
 #ifdef LIBLSAN_EARLY_SPEC
 #define LIBLSAN_SPEC STATIC_LIBLSAN_LIBS
@@ -802,7 +806,7 @@ proper position among the other output files.  */
 "} -llsan %{static-liblsan:" LD_DYNAMIC_OPTION "}" \
 STATIC_LIBLSAN_LIBS
 #else
-#define LIBLSAN_SPEC "-llsan" STATIC_LIBLSAN_LIBS
+#define LIBLSAN_SPEC "-llsan" STATIC_LIBLSAN_LIBS LIBSAN_RPATH
 #endif
 #endif

@@ -816,9 +820,9 @@ proper position among the other output files.  */
 #ifdef HAVE_LD_STATIC_DYNAMIC
 #define LIBUBSAN_SPEC "%{static-libubsan:" LD_STATIC_OPTION \
 "} -lubsan %{static-libubsan:" LD_DYNAMIC_OPTION "}" \
-STATIC_LIBUBSAN_LIBS
+STATIC_LIBUBSAN_LIBS LIBSAN_RPATH
 #else
-#define LIBUBSAN_SPEC "-lubsan" STATIC_LIBUBSAN_LIBS
+#define LIBUBSAN_SPEC "-lubsan" STATIC_LIBUBSAN_LIBS LIBSAN_RPATH
 #endif
 #endif

diff --git a/libsanitizer/Makefile.in b/libsanitizer/Makefile.in
index 65e7f2e9553..ef71407a512 100644
--- a/libsanitizer/Makefile.in
+++ b/libsanitizer/Makefile.in
@@ -333,6 +333,7 @@ libexecdir = @libexecdir@
 link_libasan = 

[PATCH] libsanitizer: don't enable for MIPS Linux without GNU libc [PR 106136]

2022-06-29 Thread Xi Ruoyao via Gcc-patches
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 submit patch to
LLVM project adding the support.

libsanitizer/ChangeLog

PR sanitizer/106136
* configure.tgt: Change mips*-*-linux* to mips*-*-linux-gnu*
because it fails to build with non-GNU libc.
---
 libsanitizer/configure.tgt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index fb89df4935c..54b74b60e2f 100644
--- a/libsanitizer/configure.tgt
+++ b/libsanitizer/configure.tgt
@@ -54,7 +54,7 @@ case "${target}" in
;;
   arm*-*-linux*)
;;
-  mips*-*-linux*)
+  mips*-*-linux-gnu*)
;;
   aarch64*-*-linux*)
if test x$ac_cv_sizeof_void_p = x8; then
-- 
2.37.0




[PATCH] libsanitizer: cherry-pick 791e0d1bc85d

2022-06-29 Thread Martin Liška

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/tsan/tsan_rtl_s390x.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libsanitizer/tsan/tsan_rtl_s390x.S 
b/libsanitizer/tsan/tsan_rtl_s390x.S
index fcff35fbc7e..2f445e8f1b2 100644
--- a/libsanitizer/tsan/tsan_rtl_s390x.S
+++ b/libsanitizer/tsan/tsan_rtl_s390x.S
@@ -45,3 +45,5 @@ intercept setjmp, _ZN14__interception11real_setjmpE
 intercept _setjmp, _ZN14__interception12real__setjmpE
 intercept sigsetjmp, _ZN14__interception14real_sigsetjmpE
 intercept __sigsetjmp, _ZN14__interception16real___sigsetjmpE
+
+NO_EXEC_STACK_DIRECTIVE
--
2.36.1



Re: [PATCH] libsanitizer: cherry-pick commit b226894d475b from upstream

2022-05-06 Thread H.J. Lu via Gcc-patches
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_linux_libcdep.cpp 
> b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
> index d966d857a76..620267cdd02 100644
> --- a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
> +++ b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
> @@ -462,7 +462,11 @@ static void GetTls(uptr *addr, uptr *size) {
>  #elif SANITIZER_GLIBC && defined(__x86_64__)
>// For aarch64 and x86-64, use an O(1) approach which requires relatively
>// precise ThreadDescriptorSize. g_tls_size was initialized in InitTlsSize.
> +#  if SANITIZER_X32
> +  asm("mov %%fs:8,%0" : "=r"(*addr));
> +#  else
>asm("mov %%fs:16,%0" : "=r"(*addr));
> +#  endif
>*size = g_tls_size;
>*addr -= *size;
>*addr += ThreadDescriptorSize();
> --
> 2.35.1
>

I am backporting this to GCC 12.

-- 
H.J.


[PATCH] libsanitizer: cherry-pick commit b226894d475b from upstream

2022-05-05 Thread H.J. Lu via Gcc-patches
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_libcdep.cpp
index d966d857a76..620267cdd02 100644
--- a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
@@ -462,7 +462,11 @@ static void GetTls(uptr *addr, uptr *size) {
 #elif SANITIZER_GLIBC && defined(__x86_64__)
   // For aarch64 and x86-64, use an O(1) approach which requires relatively
   // precise ThreadDescriptorSize. g_tls_size was initialized in InitTlsSize.
+#  if SANITIZER_X32
+  asm("mov %%fs:8,%0" : "=r"(*addr));
+#  else
   asm("mov %%fs:16,%0" : "=r"(*addr));
+#  endif
   *size = g_tls_size;
   *addr -= *size;
   *addr += ThreadDescriptorSize();
-- 
2.35.1



Re: [PATCH] libsanitizer: cherry-pick commit f52e365092aa from upstream

2022-05-05 Thread H.J. Lu via Gcc-patches
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 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 only real change is a small change in
>  gcc/testsuite/c-c++-common/asan/alloca_loop_unpoisoning.c where we
>  need --param=asan-use-after-return=0.
> 
>  I'm going to push the patches.
> >>>
> >>> Hi,
> >>>
> >>> I am checking in this patch to cherry-pick
> >>>
> >>> f52e365092aa [sanitizer] Use newfstatat for x32
> >>>
> >>> to restore x32 build.
> >>>
> >>
> >> I'm going to do one more merge from upstream
> >> (75f9e83ace52773af65dcebca543005ec8a2705d) as we want to include Tobias's
> >> revision 6f095babc2b7d564168c7afc5bf6afb2188fd6b4 and my
> >> revision f1b9245199f3457a4d06d32d1bc6e44573c166e3.
> >
> > I am testing a patch for
> >
> > https://github.com/llvm/llvm-project/issues/55288

I submitted:

https://reviews.llvm.org/D125025

> > to fix:
> >
> > https://gcc.gnu.org/pipermail/gcc-regression/2022-May/076571.html
>
> Interesting. How did you run these tests that the error shows up?

Just normal GCC bootstrap and check with x32 enabled.

> >
> > The same bug is also in GCC 12.  But somehow, it doesn't show up in
> > GCC tests.
>
> So please backport it once it's merged.
>

Will do after GCC 12 is released.

Thanks.

-- 
H.J.


Re: [PATCH] libsanitizer: cherry-pick commit f52e365092aa from upstream

2022-05-05 Thread Martin Liška
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 survives regression
 tests. I've also tested on ppc64le-linux-gnu and verified the ABI.

 The only real change is a small change in
 gcc/testsuite/c-c++-common/asan/alloca_loop_unpoisoning.c where we
 need --param=asan-use-after-return=0.

 I'm going to push the patches.
>>>
>>> Hi,
>>>
>>> I am checking in this patch to cherry-pick
>>>
>>> f52e365092aa [sanitizer] Use newfstatat for x32
>>>
>>> to restore x32 build.
>>>
>>
>> I'm going to do one more merge from upstream
>> (75f9e83ace52773af65dcebca543005ec8a2705d) as we want to include Tobias's
>> revision 6f095babc2b7d564168c7afc5bf6afb2188fd6b4 and my
>> revision f1b9245199f3457a4d06d32d1bc6e44573c166e3.
> 
> I am testing a patch for
> 
> https://github.com/llvm/llvm-project/issues/55288
> 
> to fix:
> 
> https://gcc.gnu.org/pipermail/gcc-regression/2022-May/076571.html

Interesting. How did you run these tests that the error shows up?

> 
> The same bug is also in GCC 12.  But somehow, it doesn't show up in
> GCC tests.

So please backport it once it's merged.

Martin



Re: [PATCH] libsanitizer: cherry-pick commit f52e365092aa from upstream

2022-05-05 Thread H.J. Lu via Gcc-patches
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 also tested on ppc64le-linux-gnu and verified the ABI.
> >>
> >> The only real change is a small change in
> >> gcc/testsuite/c-c++-common/asan/alloca_loop_unpoisoning.c where we
> >> need --param=asan-use-after-return=0.
> >>
> >> I'm going to push the patches.
> >
> > Hi,
> >
> > I am checking in this patch to cherry-pick
> >
> > f52e365092aa [sanitizer] Use newfstatat for x32
> >
> > to restore x32 build.
> >
>
> I'm going to do one more merge from upstream
> (75f9e83ace52773af65dcebca543005ec8a2705d) as we want to include Tobias's
> revision 6f095babc2b7d564168c7afc5bf6afb2188fd6b4 and my
> revision f1b9245199f3457a4d06d32d1bc6e44573c166e3.

I am testing a patch for

https://github.com/llvm/llvm-project/issues/55288

to fix:

https://gcc.gnu.org/pipermail/gcc-regression/2022-May/076571.html

The same bug is also in GCC 12.  But somehow, it doesn't show up in
GCC tests.

-- 
H.J.


Re: [PATCH] libsanitizer: cherry-pick commit f52e365092aa from upstream

2022-05-05 Thread Martin Liška
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 only real change is a small change in 
>> gcc/testsuite/c-c++-common/asan/alloca_loop_unpoisoning.c where we
>> need --param=asan-use-after-return=0.
>> 
>> I'm going to push the patches.
> 
> Hi,
> 
> I am checking in this patch to cherry-pick
> 
> f52e365092aa [sanitizer] Use newfstatat for x32
> 
> to restore x32 build.
> 

I'm going to do one more merge from upstream
(75f9e83ace52773af65dcebca543005ec8a2705d) as we want to include Tobias's
revision 6f095babc2b7d564168c7afc5bf6afb2188fd6b4 and my
revision f1b9245199f3457a4d06d32d1bc6e44573c166e3.

Martin


[PATCH] libsanitizer: cherry-pick commit f52e365092aa from upstream

2022-05-04 Thread H.J. Lu via Gcc-patches
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 only real change is a small change in
> gcc/testsuite/c-c++-common/asan/alloca_loop_unpoisoning.c
> where we need --param=asan-use-after-return=0.
>
> I'm going to push the patches.

Hi,

I am checking in this patch to cherry-pick

f52e365092aa [sanitizer] Use 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
---
 libsanitizer/sanitizer_common/sanitizer_linux.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libsanitizer/sanitizer_common/sanitizer_linux.cpp b/libsanitizer/sanitizer_common/sanitizer_linux.cpp
index 8e144a4e9a0..e2c32d679ad 100644
--- a/libsanitizer/sanitizer_common/sanitizer_linux.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_linux.cpp
@@ -343,7 +343,7 @@ uptr internal_stat(const char *path, void *buf) {
 #if SANITIZER_FREEBSD
   return internal_syscall(SYSCALL(fstatat), AT_FDCWD, (uptr)path, (uptr)buf, 0);
 #elif SANITIZER_LINUX
-#  if SANITIZER_WORDSIZE == 64
+#  if SANITIZER_WORDSIZE == 64 || SANITIZER_X32
   return internal_syscall(SYSCALL(newfstatat), AT_FDCWD, (uptr)path, (uptr)buf,
   0);
 #  else
@@ -366,7 +366,7 @@ uptr internal_lstat(const char *path, void *buf) {
   return internal_syscall(SYSCALL(fstatat), AT_FDCWD, (uptr)path, (uptr)buf,
   AT_SYMLINK_NOFOLLOW);
 #elif SANITIZER_LINUX
-#  if defined(_LP64)
+#  if defined(_LP64) || SANITIZER_X32
   return internal_syscall(SYSCALL(newfstatat), AT_FDCWD, (uptr)path, (uptr)buf,
   AT_SYMLINK_NOFOLLOW);
 #  else
-- 
2.35.1



[PATCH] libsanitizer: asan: Always skip first object from dl_iterate_phdr

2022-04-19 Thread Michael Forney
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 the first object (like is currently done for FreeBSD and NetBSD).
This fixes first DSO detection on Linux-musl. It also would likely
fix detection on Solaris/Illumos if it were to gain PIE support
(since dlpi_addr would not be NULL).

Additionally, only skip the Linux vDSO on Linux.

Finally, use the empty string as the "seen first dl_phdr_info"
marker rather than (char *)-1. If there was no other object, we
would try to dereference it for a string comparison.

Cherry-picked from upstream commit 795b07f5498c.

libsanitizer/

* asan/asan_linux.cpp: Always skip first object from
dl_iterate_phdr.
---
Is it possible that this change might make gcc 12? It fixes asan
on musl (without setting ASAN_OPTIONS=verify_asan_link_order=false),
which would be quite nice since this will be the first release that
libsanitizer works on musl.

 libsanitizer/asan/asan_linux.cpp | 30 --
 1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/libsanitizer/asan/asan_linux.cpp b/libsanitizer/asan/asan_linux.cpp
index ad3693d5e6a..89ee48db7a2 100644
--- a/libsanitizer/asan/asan_linux.cpp
+++ b/libsanitizer/asan/asan_linux.cpp
@@ -131,30 +131,24 @@ static int FindFirstDSOCallback(struct dl_phdr_info 
*info, size_t size,
   VReport(2, "info->dlpi_name = %s\tinfo->dlpi_addr = %p\n", info->dlpi_name,
   (void *)info->dlpi_addr);
 
-  // Continue until the first dynamic library is found
-  if (!info->dlpi_name || info->dlpi_name[0] == 0)
-return 0;
-
-  // Ignore vDSO
-  if (internal_strncmp(info->dlpi_name, "linux-", sizeof("linux-") - 1) == 0)
-return 0;
+  const char **name = (const char **)data;
 
-#if SANITIZER_FREEBSD || SANITIZER_NETBSD
   // Ignore first entry (the main program)
-  char **p = (char **)data;
-  if (!(*p)) {
-*p = (char *)-1;
+  if (!*name) {
+*name = "";
 return 0;
   }
-#endif
 
-#if SANITIZER_SOLARIS
-  // Ignore executable on Solaris
-  if (info->dlpi_addr == 0)
+#if SANITIZER_LINUX
+  // Ignore vDSO. glibc versions earlier than 2.15 (and some patched
+  // by distributors) return an empty name for the vDSO entry, so
+  // detect this as well.
+  if (!info->dlpi_name[0] ||
+  internal_strncmp(info->dlpi_name, "linux-", sizeof("linux-") - 1) == 0)
 return 0;
-#endif
+#endif
 
-  *(const char **)data = info->dlpi_name;
+  *name = info->dlpi_name;
   return 1;
 }
 
@@ -175,7 +169,7 @@ void AsanCheckDynamicRTPrereqs() {
   // Ensure that dynamic RT is the first DSO in the list
   const char *first_dso_name = nullptr;
   dl_iterate_phdr(FindFirstDSOCallback, _dso_name);
-  if (first_dso_name && !IsDynamicRTName(first_dso_name)) {
+  if (first_dso_name && first_dso_name[0] && !IsDynamicRTName(first_dso_name)) 
{
 Report("ASan runtime does not come first in initial library list; "
"you should either link runtime to your application or "
"manually preload it with LD_PRELOAD.\n");
-- 
2.35.1



Re: [GCC-11] [PATCH] libsanitizer: Cherry-pick LLVM release/13.x commit d96358a28193

2022-01-11 Thread H.J. Lu via Gcc-patches
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 branches later.

> >
> > 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 release branch as discussed on bug
> > 51620, as an alternative to backporting
> > cb0e14ce6dcdd614a7207f4ce6fcf81a164471ab and its dependencies.
> > The minimum size is 8192, as needed for the following test to pass:
> >
> >   AddressSanitizer-i386-linux :: TestCases/Linux/long-object-path.cpp
> >
> > Fixes #51620
> >
> > PR sanitizer/102911
> > * asan/asan_malloc_linux.cpp (kDlsymAllocPoolSize): Set it to
> > 8192 on Linux.
> > ---
> >  libsanitizer/asan/asan_malloc_linux.cpp | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libsanitizer/asan/asan_malloc_linux.cpp 
> > b/libsanitizer/asan/asan_malloc_linux.cpp
> > index 9c3f0a5338e..7a5776b29ed 100644
> > --- a/libsanitizer/asan/asan_malloc_linux.cpp
> > +++ b/libsanitizer/asan/asan_malloc_linux.cpp
> > @@ -31,7 +31,7 @@ using namespace __asan;
> >
> >  static uptr allocated_for_dlsym;
> >  static uptr last_dlsym_alloc_size_in_words;
> > -static const uptr kDlsymAllocPoolSize = SANITIZER_RTEMS ? 4096 : 1024;
> > +static const uptr kDlsymAllocPoolSize = SANITIZER_RTEMS ? 4096 : 8192;
> >  static uptr alloc_memory_for_dlsym[kDlsymAllocPoolSize];
> >
> >  static inline bool IsInDlsymAllocPool(const void *ptr) {
> > --
> > 2.33.1
> >

Thanks.

-- 
H.J.


Re: [GCC-11] [PATCH] libsanitizer: Cherry-pick LLVM release/13.x commit d96358a28193

2022-01-03 Thread Richard Biener via Gcc-patches
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 Dec 13 22:28:26 2021 +0100
>
> [compiler-rt] Increase kDlsymAllocPoolSize to fix test failures
>
> Increase kDlsymAllocPoolSize on the release branch as discussed on bug
> 51620, as an alternative to backporting
> cb0e14ce6dcdd614a7207f4ce6fcf81a164471ab and its dependencies.
> The minimum size is 8192, as needed for the following test to pass:
>
>   AddressSanitizer-i386-linux :: TestCases/Linux/long-object-path.cpp
>
> Fixes #51620
>
> PR sanitizer/102911
> * asan/asan_malloc_linux.cpp (kDlsymAllocPoolSize): Set it to
> 8192 on Linux.
> ---
>  libsanitizer/asan/asan_malloc_linux.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libsanitizer/asan/asan_malloc_linux.cpp 
> b/libsanitizer/asan/asan_malloc_linux.cpp
> index 9c3f0a5338e..7a5776b29ed 100644
> --- a/libsanitizer/asan/asan_malloc_linux.cpp
> +++ b/libsanitizer/asan/asan_malloc_linux.cpp
> @@ -31,7 +31,7 @@ using namespace __asan;
>
>  static uptr allocated_for_dlsym;
>  static uptr last_dlsym_alloc_size_in_words;
> -static const uptr kDlsymAllocPoolSize = SANITIZER_RTEMS ? 4096 : 1024;
> +static const uptr kDlsymAllocPoolSize = SANITIZER_RTEMS ? 4096 : 8192;
>  static uptr alloc_memory_for_dlsym[kDlsymAllocPoolSize];
>
>  static inline bool IsInDlsymAllocPool(const void *ptr) {
> --
> 2.33.1
>


Re: [PATCH] libsanitizer: Fix setbuffer() interceptor (accept size not mode)

2021-12-23 Thread Martin Liška

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.
Historically, we have taken some upstream tests, but not all. Problem is that
one needs to migrate (port) LIT markup to DejaGNU format so that it can be 
supported
in the GCC test-suite.

Cheers,
Martin


Re: [PATCH] libsanitizer: Fix setbuffer() interceptor (accept size not mode)

2021-12-22 Thread Azat Khuzhin via Gcc-patches
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 there [2].

  [1]: https://github.com/gcc-mirror/gcc/commit/b667dd7017a8
  [2]: https://github.com/llvm/llvm-project/commit/0c81a62d9d76

That's why I though that test can be ommitted in this case (I've added a
test for llvm in [3]).

  [3]: https://reviews.llvm.org/D116176

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

-- 
Azat.


Re: [PATCH] libsanitizer: Fix setbuffer() interceptor (accept size not mode)

2021-12-22 Thread Bernhard Reutner-Fischer via Gcc-patches
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,


Re: [PATCH] libsanitizer: Fix setbuffer() interceptor (accept size not mode)

2021-12-22 Thread Azat Khuzhin via Gcc-patches
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(setbuffer)(stream, buf, mode);
> 
> Where does mode come from after this patch?

Sorry, missed that.
Fixed and send v2 patch.

Thanks!


Re: [PATCH] libsanitizer: Fix setbuffer() interceptor (accept size not mode)

2021-12-22 Thread Azat Khuzhin via Gcc-patches
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_common_interceptors.inc | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> >diff --git a/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc 
> >b/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc
> >index abb38ccfa15..60b0545a943 100644
> >--- a/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc
> >+++ b/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc
> >@@ -7858,12 +7858,13 @@ INTERCEPTOR(void, setbuf, __sanitizer_FILE *stream, 
> >char *buf) {
> >   unpoison_file(stream);
> > }
> > 
> >-INTERCEPTOR(void, setbuffer, __sanitizer_FILE *stream, char *buf, int mode) 
> >{
> >+INTERCEPTOR(void, setbuffer, __sanitizer_FILE *stream, char *buf,
> >+  SIZE_T size) {
> >   void *ctx;
> >-  COMMON_INTERCEPTOR_ENTER(ctx, setbuffer, stream, buf, mode);
> >+  COMMON_INTERCEPTOR_ENTER(ctx, setbuffer, stream, buf, size);
> >   REAL(setbuffer)(stream, buf, mode);
> 
> Where does mode come from after this patch?

setbuffer() does not accept mode, it simply do not change it.
Only setvbuf() can change the mode.

> thanks,
> 
> >   if (buf) {
> >-COMMON_INTERCEPTOR_WRITE_RANGE(ctx, buf, __sanitizer_bufsiz);
> >+COMMON_INTERCEPTOR_WRITE_RANGE(ctx, buf, size);
> >   }
> >   if (stream)
> > unpoison_file(stream);
> 


Re: [PATCH] libsanitizer: Fix setbuffer() interceptor (accept size not mode)

2021-12-22 Thread Bernhard Reutner-Fischer via Gcc-patches
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(-)
>
>diff --git a/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc 
>b/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc
>index abb38ccfa15..60b0545a943 100644
>--- a/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc
>+++ b/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc
>@@ -7858,12 +7858,13 @@ INTERCEPTOR(void, setbuf, __sanitizer_FILE *stream, 
>char *buf) {
>   unpoison_file(stream);
> }
> 
>-INTERCEPTOR(void, setbuffer, __sanitizer_FILE *stream, char *buf, int mode) {
>+INTERCEPTOR(void, setbuffer, __sanitizer_FILE *stream, char *buf,
>+  SIZE_T size) {
>   void *ctx;
>-  COMMON_INTERCEPTOR_ENTER(ctx, setbuffer, stream, buf, mode);
>+  COMMON_INTERCEPTOR_ENTER(ctx, setbuffer, stream, buf, size);
>   REAL(setbuffer)(stream, buf, mode);

Where does mode come from after this patch?
thanks,

>   if (buf) {
>-COMMON_INTERCEPTOR_WRITE_RANGE(ctx, buf, __sanitizer_bufsiz);
>+COMMON_INTERCEPTOR_WRITE_RANGE(ctx, buf, size);
>   }
>   if (stream)
> unpoison_file(stream);



[PATCH] libsanitizer: Fix setbuffer() interceptor (accept size not mode)

2021-12-22 Thread Azat Khuzhin via Gcc-patches
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.inc 
b/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc
index abb38ccfa15..60b0545a943 100644
--- a/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc
+++ b/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc
@@ -7858,12 +7858,13 @@ INTERCEPTOR(void, setbuf, __sanitizer_FILE *stream, 
char *buf) {
   unpoison_file(stream);
 }
 
-INTERCEPTOR(void, setbuffer, __sanitizer_FILE *stream, char *buf, int mode) {
+INTERCEPTOR(void, setbuffer, __sanitizer_FILE *stream, char *buf,
+  SIZE_T size) {
   void *ctx;
-  COMMON_INTERCEPTOR_ENTER(ctx, setbuffer, stream, buf, mode);
+  COMMON_INTERCEPTOR_ENTER(ctx, setbuffer, stream, buf, size);
   REAL(setbuffer)(stream, buf, mode);
   if (buf) {
-COMMON_INTERCEPTOR_WRITE_RANGE(ctx, buf, __sanitizer_bufsiz);
+COMMON_INTERCEPTOR_WRITE_RANGE(ctx, buf, size);
   }
   if (stream)
 unpoison_file(stream);
-- 
2.33.1



[GCC-11] [PATCH] libsanitizer: Cherry-pick LLVM release/13.x commit d96358a28193

2021-12-17 Thread H.J. Lu via Gcc-patches
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 release branch as discussed on bug
51620, as an alternative to backporting
cb0e14ce6dcdd614a7207f4ce6fcf81a164471ab and its dependencies.
The minimum size is 8192, as needed for the following test to pass:

  AddressSanitizer-i386-linux :: TestCases/Linux/long-object-path.cpp

Fixes #51620

PR sanitizer/102911
* asan/asan_malloc_linux.cpp (kDlsymAllocPoolSize): Set it to
8192 on Linux.
---
 libsanitizer/asan/asan_malloc_linux.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libsanitizer/asan/asan_malloc_linux.cpp 
b/libsanitizer/asan/asan_malloc_linux.cpp
index 9c3f0a5338e..7a5776b29ed 100644
--- a/libsanitizer/asan/asan_malloc_linux.cpp
+++ b/libsanitizer/asan/asan_malloc_linux.cpp
@@ -31,7 +31,7 @@ using namespace __asan;
 
 static uptr allocated_for_dlsym;
 static uptr last_dlsym_alloc_size_in_words;
-static const uptr kDlsymAllocPoolSize = SANITIZER_RTEMS ? 4096 : 1024;
+static const uptr kDlsymAllocPoolSize = SANITIZER_RTEMS ? 4096 : 8192;
 static uptr alloc_memory_for_dlsym[kDlsymAllocPoolSize];
 
 static inline bool IsInDlsymAllocPool(const void *ptr) {
-- 
2.33.1



Re: [PATCH] libsanitizer: Use SSE to save and restore XMM registers

2021-12-06 Thread Jakub Jelinek via Gcc-patches
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 removed in
> 
> https://reviews.llvm.org/D112604
> 
> This fixed
> 
> FAIL: g++.dg/tsan/pthread_cond_clockwait.C   -O0  execution test
> FAIL: g++.dg/tsan/pthread_cond_clockwait.C   -O2  execution test
> 
> on machines without AVX.
> 
>   PR sanitizer/103466
>   * tsan/tsan_rtl_amd64.S (__tsan_trace_switch_thunk): Replace
>   vmovdqu with movdqu.
>   (__tsan_report_race_thunk): Likewise.

Ok, thanks.

Jakub



[PATCH] libsanitizer: Use SSE to save and restore XMM registers

2021-11-30 Thread H.J. Lu via Gcc-patches
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_cond_clockwait.C   -O0  execution test
FAIL: g++.dg/tsan/pthread_cond_clockwait.C   -O2  execution test

on machines without AVX.

PR sanitizer/103466
* tsan/tsan_rtl_amd64.S (__tsan_trace_switch_thunk): Replace
vmovdqu with movdqu.
(__tsan_report_race_thunk): Likewise.
---
 libsanitizer/tsan/tsan_rtl_amd64.S | 128 ++---
 1 file changed, 64 insertions(+), 64 deletions(-)

diff --git a/libsanitizer/tsan/tsan_rtl_amd64.S 
b/libsanitizer/tsan/tsan_rtl_amd64.S
index 632b19d1815..c15b01e49e5 100644
--- a/libsanitizer/tsan/tsan_rtl_amd64.S
+++ b/libsanitizer/tsan/tsan_rtl_amd64.S
@@ -45,22 +45,22 @@ ASM_SYMBOL(__tsan_trace_switch_thunk):
   # All XMM registers are caller-saved.
   sub $0x100, %rsp
   CFI_ADJUST_CFA_OFFSET(0x100)
-  vmovdqu %xmm0, 0x0(%rsp)
-  vmovdqu %xmm1, 0x10(%rsp)
-  vmovdqu %xmm2, 0x20(%rsp)
-  vmovdqu %xmm3, 0x30(%rsp)
-  vmovdqu %xmm4, 0x40(%rsp)
-  vmovdqu %xmm5, 0x50(%rsp)
-  vmovdqu %xmm6, 0x60(%rsp)
-  vmovdqu %xmm7, 0x70(%rsp)
-  vmovdqu %xmm8, 0x80(%rsp)
-  vmovdqu %xmm9, 0x90(%rsp)
-  vmovdqu %xmm10, 0xa0(%rsp)
-  vmovdqu %xmm11, 0xb0(%rsp)
-  vmovdqu %xmm12, 0xc0(%rsp)
-  vmovdqu %xmm13, 0xd0(%rsp)
-  vmovdqu %xmm14, 0xe0(%rsp)
-  vmovdqu %xmm15, 0xf0(%rsp)
+  movdqu %xmm0, 0x0(%rsp)
+  movdqu %xmm1, 0x10(%rsp)
+  movdqu %xmm2, 0x20(%rsp)
+  movdqu %xmm3, 0x30(%rsp)
+  movdqu %xmm4, 0x40(%rsp)
+  movdqu %xmm5, 0x50(%rsp)
+  movdqu %xmm6, 0x60(%rsp)
+  movdqu %xmm7, 0x70(%rsp)
+  movdqu %xmm8, 0x80(%rsp)
+  movdqu %xmm9, 0x90(%rsp)
+  movdqu %xmm10, 0xa0(%rsp)
+  movdqu %xmm11, 0xb0(%rsp)
+  movdqu %xmm12, 0xc0(%rsp)
+  movdqu %xmm13, 0xd0(%rsp)
+  movdqu %xmm14, 0xe0(%rsp)
+  movdqu %xmm15, 0xf0(%rsp)
   # Align stack frame.
   push %rbx  # non-scratch
   CFI_ADJUST_CFA_OFFSET(8)
@@ -78,22 +78,22 @@ ASM_SYMBOL(__tsan_trace_switch_thunk):
   pop %rbx
   CFI_ADJUST_CFA_OFFSET(-8)
   # Restore scratch registers.
-  vmovdqu 0x0(%rsp), %xmm0
-  vmovdqu 0x10(%rsp), %xmm1
-  vmovdqu 0x20(%rsp), %xmm2
-  vmovdqu 0x30(%rsp), %xmm3
-  vmovdqu 0x40(%rsp), %xmm4
-  vmovdqu 0x50(%rsp), %xmm5
-  vmovdqu 0x60(%rsp), %xmm6
-  vmovdqu 0x70(%rsp), %xmm7
-  vmovdqu 0x80(%rsp), %xmm8
-  vmovdqu 0x90(%rsp), %xmm9
-  vmovdqu 0xa0(%rsp), %xmm10
-  vmovdqu 0xb0(%rsp), %xmm11
-  vmovdqu 0xc0(%rsp), %xmm12
-  vmovdqu 0xd0(%rsp), %xmm13
-  vmovdqu 0xe0(%rsp), %xmm14
-  vmovdqu 0xf0(%rsp), %xmm15
+  movdqu 0x0(%rsp), %xmm0
+  movdqu 0x10(%rsp), %xmm1
+  movdqu 0x20(%rsp), %xmm2
+  movdqu 0x30(%rsp), %xmm3
+  movdqu 0x40(%rsp), %xmm4
+  movdqu 0x50(%rsp), %xmm5
+  movdqu 0x60(%rsp), %xmm6
+  movdqu 0x70(%rsp), %xmm7
+  movdqu 0x80(%rsp), %xmm8
+  movdqu 0x90(%rsp), %xmm9
+  movdqu 0xa0(%rsp), %xmm10
+  movdqu 0xb0(%rsp), %xmm11
+  movdqu 0xc0(%rsp), %xmm12
+  movdqu 0xd0(%rsp), %xmm13
+  movdqu 0xe0(%rsp), %xmm14
+  movdqu 0xf0(%rsp), %xmm15
   add $0x100, %rsp
   CFI_ADJUST_CFA_OFFSET(-0x100)
   pop %r11
@@ -163,22 +163,22 @@ ASM_SYMBOL(__tsan_report_race_thunk):
   # All XMM registers are caller-saved.
   sub $0x100, %rsp
   CFI_ADJUST_CFA_OFFSET(0x100)
-  vmovdqu %xmm0, 0x0(%rsp)
-  vmovdqu %xmm1, 0x10(%rsp)
-  vmovdqu %xmm2, 0x20(%rsp)
-  vmovdqu %xmm3, 0x30(%rsp)
-  vmovdqu %xmm4, 0x40(%rsp)
-  vmovdqu %xmm5, 0x50(%rsp)
-  vmovdqu %xmm6, 0x60(%rsp)
-  vmovdqu %xmm7, 0x70(%rsp)
-  vmovdqu %xmm8, 0x80(%rsp)
-  vmovdqu %xmm9, 0x90(%rsp)
-  vmovdqu %xmm10, 0xa0(%rsp)
-  vmovdqu %xmm11, 0xb0(%rsp)
-  vmovdqu %xmm12, 0xc0(%rsp)
-  vmovdqu %xmm13, 0xd0(%rsp)
-  vmovdqu %xmm14, 0xe0(%rsp)
-  vmovdqu %xmm15, 0xf0(%rsp)
+  movdqu %xmm0, 0x0(%rsp)
+  movdqu %xmm1, 0x10(%rsp)
+  movdqu %xmm2, 0x20(%rsp)
+  movdqu %xmm3, 0x30(%rsp)
+  movdqu %xmm4, 0x40(%rsp)
+  movdqu %xmm5, 0x50(%rsp)
+  movdqu %xmm6, 0x60(%rsp)
+  movdqu %xmm7, 0x70(%rsp)
+  movdqu %xmm8, 0x80(%rsp)
+  movdqu %xmm9, 0x90(%rsp)
+  movdqu %xmm10, 0xa0(%rsp)
+  movdqu %xmm11, 0xb0(%rsp)
+  movdqu %xmm12, 0xc0(%rsp)
+  movdqu %xmm13, 0xd0(%rsp)
+  movdqu %xmm14, 0xe0(%rsp)
+  movdqu %xmm15, 0xf0(%rsp)
   # Align stack frame.
   push %rbx  # non-scratch
   CFI_ADJUST_CFA_OFFSET(8)
@@ -196,22 +196,22 @@ ASM_SYMBOL(__tsan_report_race_thunk):
   pop %rbx
   CFI_ADJUST_CFA_OFFSET(-8)
   # Restore scratch registers.
-  vmovdqu 0x0(%rsp), %xmm0
-  vmovdqu 0x10(%rsp), %xmm1
-  vmovdqu 0x20(%rsp), %xmm2
-  vmovdqu 0x30(%rsp), %xmm3
-  vmovdqu 0x40(%rsp), %xmm4
-  vmovdqu 0x50(%rsp), %xmm5
-  vmovdqu 0x60(%rsp), %xmm6
-  vmovdqu 0x70(%rsp), %xmm7
-  vmovdqu 0x80(%rsp), %xmm8
-  vmovdqu 0x90(%rsp), %xmm9
-  vmovdqu 0xa0(%rsp), %xmm10
-  vmovdqu 0xb0(%rsp), %xmm11
-  vmovdqu 0xc0(%rsp), %xmm12
-  vmovdqu 0xd0(%rsp), %xmm13
-  vmovdqu 0xe0(%rsp), %xmm14
-  vmovdqu 0xf0(%rsp), %xmm15
+  movdqu 0x0(%rsp), %xmm0
+  

Re: [PATCH] libsanitizer: Fix bootstrap on FreeBSD [PR102675]

2021-11-18 Thread Richard Biener via Gcc-patches
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 don't need to cary a local patch for that
> particular problem.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux (verified that
> -DUSE_SYSTEM_MD5 is passed only when compiling
> sanitizer_platform_limits_freebsd.cpp) and Gerald in the PR said
> it passed bootstrap on FreeBSD as well.
> 
> Ok for trunk?

OK.

> 2021-11-17  Jakub Jelinek  
> 
>   PR bootstrap/102675
>   * sanitizer_common/Makefile.am: Use -DUSE_SYSTEM_MD5 in AM_CXXFLAGS
>   of sanitizer_platform_limits_freebsd.cpp.
>   * sanitizer_common/Makefile.in: Regenerated.
> 
> --- libsanitizer/sanitizer_common/Makefile.am.jj  2021-11-05 
> 00:43:22.647623646 +0100
> +++ libsanitizer/sanitizer_common/Makefile.am 2021-11-16 12:29:58.574930436 
> +0100
> @@ -17,6 +17,7 @@ AM_CXXFLAGS += -DSANITIZER_LIBBACKTRACE
>  endif
>  AM_CCASFLAGS = $(EXTRA_ASFLAGS)
>  ACLOCAL_AMFLAGS = -I m4
> +sanitizer_platform_limits_freebsd.lo: AM_CXXFLAGS += -DUSE_SYSTEM_MD5
>  
>  noinst_LTLIBRARIES = libsanitizer_common.la
>  
> --- libsanitizer/sanitizer_common/Makefile.in.jj  2021-11-05 
> 00:43:22.647623646 +0100
> +++ libsanitizer/sanitizer_common/Makefile.in 2021-11-16 12:30:58.611088913 
> +0100
> @@ -796,6 +796,7 @@ uninstall-am:
>  
>  .PRECIOUS: Makefile
>  
> +sanitizer_platform_limits_freebsd.lo: AM_CXXFLAGS += -DUSE_SYSTEM_MD5
>  
>  # Tell versions [3.59,3.63) of GNU make to not export all variables.
>  # Otherwise a system limit (for SysV at least) may be exceeded.
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)


[PATCH] libsanitizer: Fix bootstrap on FreeBSD [PR102675]

2021-11-17 Thread Jakub Jelinek via Gcc-patches
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 problem.

Bootstrapped/regtested on x86_64-linux and i686-linux (verified that
-DUSE_SYSTEM_MD5 is passed only when compiling
sanitizer_platform_limits_freebsd.cpp) and Gerald in the PR said
it passed bootstrap on FreeBSD as well.

Ok for trunk?

2021-11-17  Jakub Jelinek  

PR bootstrap/102675
* sanitizer_common/Makefile.am: Use -DUSE_SYSTEM_MD5 in AM_CXXFLAGS
of sanitizer_platform_limits_freebsd.cpp.
* sanitizer_common/Makefile.in: Regenerated.

--- libsanitizer/sanitizer_common/Makefile.am.jj2021-11-05 
00:43:22.647623646 +0100
+++ libsanitizer/sanitizer_common/Makefile.am   2021-11-16 12:29:58.574930436 
+0100
@@ -17,6 +17,7 @@ AM_CXXFLAGS += -DSANITIZER_LIBBACKTRACE
 endif
 AM_CCASFLAGS = $(EXTRA_ASFLAGS)
 ACLOCAL_AMFLAGS = -I m4
+sanitizer_platform_limits_freebsd.lo: AM_CXXFLAGS += -DUSE_SYSTEM_MD5
 
 noinst_LTLIBRARIES = libsanitizer_common.la
 
--- libsanitizer/sanitizer_common/Makefile.in.jj2021-11-05 
00:43:22.647623646 +0100
+++ libsanitizer/sanitizer_common/Makefile.in   2021-11-16 12:30:58.611088913 
+0100
@@ -796,6 +796,7 @@ uninstall-am:
 
 .PRECIOUS: Makefile
 
+sanitizer_platform_limits_freebsd.lo: AM_CXXFLAGS += -DUSE_SYSTEM_MD5
 
 # Tell versions [3.59,3.63) of GNU make to not export all variables.
 # Otherwise a system limit (for SysV at least) may be exceeded.

Jakub



[PATCH] libsanitizer: Merge with upstream

2021-11-13 Thread H.J. Lu via Gcc-patches
Merged revision: 82bc6a094e85014f1891ef9407496f44af8fe442

with the fix for PR sanitizer/102911
---
 libsanitizer/MERGE|   2 +-
 libsanitizer/asan/asan_allocator.cpp  |  17 ++-
 libsanitizer/asan/asan_globals.cpp|  19 +++
 libsanitizer/asan/asan_interceptors.h |   7 +-
 libsanitizer/asan/asan_malloc_linux.cpp   | 115 --
 libsanitizer/asan/asan_mapping.h  |   2 +-
 libsanitizer/hwasan/hwasan.cpp|   2 +-
 .../hwasan/hwasan_allocation_functions.cpp|  59 +++--
 libsanitizer/hwasan/hwasan_exceptions.cpp |   4 +-
 libsanitizer/hwasan/hwasan_fuchsia.cpp|   2 +-
 libsanitizer/hwasan/hwasan_linux.cpp  |   2 +-
 libsanitizer/hwasan/hwasan_thread.cpp |  22 ++--
 libsanitizer/hwasan/hwasan_thread.h   |  10 +-
 libsanitizer/lsan/lsan_common.cpp |  31 ++---
 libsanitizer/lsan/lsan_common.h   |   9 +-
 libsanitizer/lsan/lsan_common_mac.cpp |   2 +-
 libsanitizer/lsan/lsan_interceptors.cpp   |  44 ---
 .../sanitizer_common/sanitizer_addrhashmap.h  |  38 ++
 .../sanitizer_allocator_combined.h|   6 +-
 .../sanitizer_allocator_dlsym.h   |  79 
 .../sanitizer_allocator_primary32.h   |   6 +-
 .../sanitizer_allocator_secondary.h   |   8 +-
 .../sanitizer_deadlock_detector.h |   2 +-
 .../sanitizer_common/sanitizer_linux.cpp  |  48 +---
 .../sanitizer_common/sanitizer_linux.h|  12 +-
 .../sanitizer_linux_libcdep.cpp   |   4 -
 .../sanitizer_common/sanitizer_mac.cpp|  15 +--
 libsanitizer/sanitizer_common/sanitizer_mac.h |  20 ---
 .../sanitizer_common/sanitizer_malloc_mac.inc |  20 ++-
 .../sanitizer_platform_interceptors.h |   6 +-
 .../sanitizer_platform_limits_linux.cpp   |   5 +-
 .../sanitizer_platform_limits_posix.h |   2 +-
 .../sanitizer_common/sanitizer_procmaps.h |  18 ++-
 .../sanitizer_common/sanitizer_stacktrace.cpp |  17 +--
 libsanitizer/tsan/tsan_interceptors_posix.cpp |  38 +-
 libsanitizer/tsan/tsan_rtl.cpp|   6 +-
 libsanitizer/tsan/tsan_rtl.h  |   2 +-
 libsanitizer/tsan/tsan_rtl_amd64.S|  74 +++
 libsanitizer/tsan/tsan_rtl_ppc64.S|   1 -
 libsanitizer/ubsan/ubsan_flags.cpp|   1 -
 libsanitizer/ubsan/ubsan_handlers.cpp |  15 ---
 libsanitizer/ubsan/ubsan_handlers.h   |   8 --
 libsanitizer/ubsan/ubsan_platform.h   |   2 -
 43 files changed, 469 insertions(+), 333 deletions(-)
 create mode 100644 libsanitizer/sanitizer_common/sanitizer_allocator_dlsym.h

diff --git a/libsanitizer/MERGE b/libsanitizer/MERGE
index c3463bffbae..01913de5d66 100644
--- a/libsanitizer/MERGE
+++ b/libsanitizer/MERGE
@@ -1,4 +1,4 @@
-78d3e0a4f1406b17cdecc77540e09210670fe9a9
+82bc6a094e85014f1891ef9407496f44af8fe442
 
 The first line of this file holds the git revision number of the
 last merge done from the master library sources.
diff --git a/libsanitizer/asan/asan_allocator.cpp 
b/libsanitizer/asan/asan_allocator.cpp
index 6d7073710bd..3fa36742060 100644
--- a/libsanitizer/asan/asan_allocator.cpp
+++ b/libsanitizer/asan/asan_allocator.cpp
@@ -102,19 +102,18 @@ class ChunkHeader {
 
  public:
   uptr UsedSize() const {
-uptr R = user_requested_size_lo;
-if (sizeof(uptr) > sizeof(user_requested_size_lo))
-  R += (uptr)user_requested_size_hi << (8 * 
sizeof(user_requested_size_lo));
-return R;
+static_assert(sizeof(user_requested_size_lo) == 4,
+  "Expression below requires this");
+return FIRST_32_SECOND_64(0, ((uptr)user_requested_size_hi << 32)) +
+   user_requested_size_lo;
   }
 
   void SetUsedSize(uptr size) {
 user_requested_size_lo = size;
-if (sizeof(uptr) > sizeof(user_requested_size_lo)) {
-  size >>= (8 * sizeof(user_requested_size_lo));
-  user_requested_size_hi = size;
-  CHECK_EQ(user_requested_size_hi, size);
-}
+static_assert(sizeof(user_requested_size_lo) == 4,
+  "Expression below requires this");
+user_requested_size_hi = FIRST_32_SECOND_64(0, size >> 32);
+CHECK_EQ(UsedSize(), size);
   }
 
   void SetAllocContext(u32 tid, u32 stack) {
diff --git a/libsanitizer/asan/asan_globals.cpp 
b/libsanitizer/asan/asan_globals.cpp
index 94004877227..5f56fe6f457 100644
--- a/libsanitizer/asan/asan_globals.cpp
+++ b/libsanitizer/asan/asan_globals.cpp
@@ -154,6 +154,23 @@ static void CheckODRViolationViaIndicator(const Global *g) 
{
   }
 }
 
+// Check ODR violation for given global G by checking if it's already poisoned.
+// We use this method in case compiler doesn't use private aliases for global
+// variables.
+static void CheckODRViolationViaPoisoning(const Global *g) {
+  if (__asan_region_is_poisoned(g->beg, g->size_with_redzone)) {
+// This check may not be enough: if the first global is much larger
+

Re: [PATCH] libsanitizer: Disable libbacktrace on sanitizer_platform_limits_freebsd.cpp

2021-11-07 Thread Gerald Pfeifer
On Thu, 4 Nov 2021, H.J. Lu wrote:
>> Ok.  But please after committing mention the revision in
>> libsanitizer/LOCAL_PATCHES.
> include and libsanitizer should use 2 separate patches.  The 
> libsanitizer patch should be in libsanitizer/LOCAL_PATCHES.

Okay, thanks.

This is the first part I committed on Friday, the second will 
follow today.

Gerald


commit 44d9d55c6d0e3a1e26427662d30f350a80282634
Author: Gerald Pfeifer 
Date:   Fri Nov 5 12:56:07 2021 +0100

include: Allow for our md5.h to defer to the system header

This came up in the context of libsanitizer, where platform-specific
support for FreeBSD relies on aspects provided by FreeBSD's own md5.h.

Address this by allowing GCC's md5.h to pull in the system header
instead, controlled by a new macro USE_SYSTEM_MD5.

2021-11-05  Gerald Pfeifer  
Jakub Jelinek  

include/
* md5.h (USE_SYSTEM_MD5): Introduce.

diff --git a/include/md5.h b/include/md5.h
index 03f7d29afc7..c5bb6076969 100644
--- a/include/md5.h
+++ b/include/md5.h
@@ -21,6 +21,10 @@
 #ifndef _MD5_H
 #define _MD5_H 1
 
+#ifdef USE_SYSTEM_MD5
+#include_next 
+#else
+
 #include 
 
 #if defined HAVE_LIMITS_H || _LIBC
@@ -151,4 +155,6 @@ extern void *md5_buffer (const char *buffer, size_t len, 
void *resblock);
 }
 #endif
 
+#endif // USE_SYSTEM_MD5
+
 #endif


Re: [PATCH] libsanitizer: remove -pedantic option

2021-11-05 Thread Martin Liška

On 11/5/21 16:29, Jakub Jelinek wrote:

On Fri, Nov 05, 2021 at 04:25:53PM +0100, Martin Liška wrote:

On 11/5/21 16:22, H.J. Lu wrote:

Should we add __extension__ here?


I tried doing that but it didn't help me with the warning.
Maybe I did something wrong?


Works for me just fine say on:
void foo ()
{
   int a = ({ int d = 1; d; });
   int b = __extension__ ({ int d = 1; d; });
}
-Wpedantic warning on line 3, none on line 4.  Add -D__extension__=
and it warns on both.

Jakub



Thank you both, it really work. I wrongly put the keyword to the first
statement in curly braces.

I'm going to suggest that to the upstream.

Cheers,
Martin


Re: [PATCH] libsanitizer: remove -pedantic option

2021-11-05 Thread H.J. Lu via Gcc-patches
On Fri, Nov 5, 2021 at 8:25 AM Martin Liška  wrote:
>
> On 11/5/21 16:22, H.J. Lu wrote:
> > Should we add __extension__ here?
>
> I tried doing that but it didn't help me with the warning.
> Maybe I did something wrong?

[hjl@gnu-cfl-2 tmp]$ cat y.cc
#include 

#define uptr uintptr_t

#  define GET_CURRENT_PC()\
   (__extension__ ({  \
  uptr pc;\
  asm("lea 0(%%rip), %0" : "=r"(pc)); \
  pc; \
}))

uptr
foo (void)
{
  return GET_CURRENT_PC ();
}
[hjl@gnu-cfl-2 tmp]$ gcc -S -O2 y.cc -pedantic
[hjl@gnu-cfl-2 tmp]$


-- 
H.J.


Re: [PATCH] libsanitizer: remove -pedantic option

2021-11-05 Thread Jakub Jelinek via Gcc-patches
On Fri, Nov 05, 2021 at 04:25:53PM +0100, Martin Liška wrote:
> On 11/5/21 16:22, H.J. Lu wrote:
> > Should we add __extension__ here?
> 
> I tried doing that but it didn't help me with the warning.
> Maybe I did something wrong?

Works for me just fine say on:
void foo ()
{
  int a = ({ int d = 1; d; });
  int b = __extension__ ({ int d = 1; d; });
}
-Wpedantic warning on line 3, none on line 4.  Add -D__extension__=
and it warns on both.

Jakub



Re: [PATCH] libsanitizer: remove -pedantic option

2021-11-05 Thread Martin Liška

On 11/5/21 16:22, H.J. Lu wrote:

Should we add __extension__ here?


I tried doing that but it didn't help me with the warning.
Maybe I did something wrong?

Cheers,
Martin


Re: [PATCH] libsanitizer: remove -pedantic option

2021-11-05 Thread H.J. Lu via Gcc-patches
On Fri, Nov 5, 2021 at 8:00 AM Martin Liška  wrote:
>
> The code uses intentionally braced-groups within expressions:
>
>  ({\

Should we add __extension__ here?

>uptr pc;\
>asm("lea 0(%%rip), %0" : "=r"(pc)); \
>pc; \
>  })
>
> And we emit gazillion of warnings now:
>
> /home/marxin/Programming/gcc/libsanitizer/tsan/tsan_interceptors_posix.cpp: 
> In function ‘int sigaction_impl(int, const 
> __sanitizer::__sanitizer_sigaction*, __sanitizer::__sanitizer_sigaction*)’:
> /home/marxin/Programming/gcc/libsanitizer/sanitizer_common/sanitizer_stacktrace.h:212:5:
>  warning: ISO C++ forbids braced-groups within expressions [-Wpedantic]
>212 | ({\
>| ^
> /home/marxin/Programming/gcc/libsanitizer/tsan/tsan_interceptors.h:44:26: 
> note: in expansion of macro ‘GET_CURRENT_PC’
> 44 |   UNUSED const uptr pc = GET_CURRENT_PC();
>|  ^~
>
> Ready to be installed?
> Thanks,
> Martin
>
> libsanitizer/ChangeLog:
>
> * asan/Makefile.am: Remove -pedantic option.
> * asan/Makefile.in: Likewise.
> * hwasan/Makefile.am: Likewise.
> * hwasan/Makefile.in: Likewise.
> * interception/Makefile.am: Likewise.
> * interception/Makefile.in: Likewise.
> * lsan/Makefile.am: Likewise.
> * lsan/Makefile.in: Likewise.
> * sanitizer_common/Makefile.am: Likewise.
> * sanitizer_common/Makefile.in: Likewise.
> * tsan/Makefile.am: Likewise.
> * tsan/Makefile.in: Likewise.
> * ubsan/Makefile.am: Likewise.
> * ubsan/Makefile.in: Likewise.
> ---
>   libsanitizer/asan/Makefile.am | 2 +-
>   libsanitizer/asan/Makefile.in | 2 +-
>   libsanitizer/hwasan/Makefile.am   | 2 +-
>   libsanitizer/hwasan/Makefile.in   | 2 +-
>   libsanitizer/interception/Makefile.am | 2 +-
>   libsanitizer/interception/Makefile.in | 2 +-
>   libsanitizer/lsan/Makefile.am | 2 +-
>   libsanitizer/lsan/Makefile.in | 2 +-
>   libsanitizer/sanitizer_common/Makefile.am | 2 +-
>   libsanitizer/sanitizer_common/Makefile.in | 2 +-
>   libsanitizer/tsan/Makefile.am | 2 +-
>   libsanitizer/tsan/Makefile.in | 2 +-
>   libsanitizer/ubsan/Makefile.am| 2 +-
>   libsanitizer/ubsan/Makefile.in| 2 +-
>   14 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/libsanitizer/asan/Makefile.am b/libsanitizer/asan/Makefile.am
> index 4f802f723d6..7270116cf71 100644
> --- a/libsanitizer/asan/Makefile.am
> +++ b/libsanitizer/asan/Makefile.am
> @@ -7,7 +7,7 @@ DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS 
> -D__STDC_FORMAT_MACROS -D
>   if USING_MAC_INTERPOSE
>   DEFS += -DMAC_INTERPOSE_FUNCTIONS -DMISSING_BLOCKS_SUPPORT
>   endif
> -AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic 
> -Wno-long-long  -fPIC -fno-builtin -fno-exceptions -fno-rtti 
> -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros 
> -fno-ipa-icf
> +AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-long-long  
> -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer 
> -funwind-tables -fvisibility=hidden -Wno-variadic-macros -fno-ipa-icf
>   AM_CXXFLAGS += $(LIBSTDCXX_RAW_CXX_CXXFLAGS)
>   AM_CXXFLAGS += -std=gnu++14
>   AM_CXXFLAGS += $(EXTRA_CXXFLAGS)
> diff --git a/libsanitizer/asan/Makefile.in b/libsanitizer/asan/Makefile.in
> index 528ab61312c..26971051b82 100644
> --- a/libsanitizer/asan/Makefile.in
> +++ b/libsanitizer/asan/Makefile.in
> @@ -416,7 +416,7 @@ AM_CPPFLAGS = -I $(top_srcdir)/include -I $(top_srcdir)
>
>   # May be used by toolexeclibdir.
>   gcc_version := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER)
> -AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic \
> +AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings \
> -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti \
> -fomit-frame-pointer -funwind-tables -fvisibility=hidden \
> -Wno-variadic-macros -fno-ipa-icf \
> diff --git a/libsanitizer/hwasan/Makefile.am b/libsanitizer/hwasan/Makefile.am
> index e12c0a0ce71..9fd39953789 100644
> --- a/libsanitizer/hwasan/Makefile.am
> +++ b/libsanitizer/hwasan/Makefile.am
> @@ -4,7 +4,7 @@ AM_CPPFLAGS = -I $(top_srcdir)/include -I $(top_srcdir)
>   gcc_version := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER)
>
>   DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS 
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DCAN_SANITIZE_UB=0 
> -DHWASAN_WITH_INTERCEPTORS=1
> -AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic 
> -Wno-long-long  -fPIC -fno-builtin -fno-exceptions -fno-rtti -funwind-tables 
> -fvisibility=hidden -Wno-variadic-macros -fno-ipa-icf
> +AM_CXXFLAGS = 

[PATCH] libsanitizer: remove -pedantic option

2021-11-05 Thread Martin Liška

The code uses intentionally braced-groups within expressions:

({\
  uptr pc;\
  asm("lea 0(%%rip), %0" : "=r"(pc)); \
  pc; \
})

And we emit gazillion of warnings now:

/home/marxin/Programming/gcc/libsanitizer/tsan/tsan_interceptors_posix.cpp: In 
function ‘int sigaction_impl(int, const __sanitizer::__sanitizer_sigaction*, 
__sanitizer::__sanitizer_sigaction*)’:
/home/marxin/Programming/gcc/libsanitizer/sanitizer_common/sanitizer_stacktrace.h:212:5:
 warning: ISO C++ forbids braced-groups within expressions [-Wpedantic]
  212 | ({\
  | ^
/home/marxin/Programming/gcc/libsanitizer/tsan/tsan_interceptors.h:44:26: note: 
in expansion of macro ‘GET_CURRENT_PC’
   44 |   UNUSED const uptr pc = GET_CURRENT_PC();
  |  ^~

Ready to be installed?
Thanks,
Martin

libsanitizer/ChangeLog:

* asan/Makefile.am: Remove -pedantic option.
* asan/Makefile.in: Likewise.
* hwasan/Makefile.am: Likewise.
* hwasan/Makefile.in: Likewise.
* interception/Makefile.am: Likewise.
* interception/Makefile.in: Likewise.
* lsan/Makefile.am: Likewise.
* lsan/Makefile.in: Likewise.
* sanitizer_common/Makefile.am: Likewise.
* sanitizer_common/Makefile.in: Likewise.
* tsan/Makefile.am: Likewise.
* tsan/Makefile.in: Likewise.
* ubsan/Makefile.am: Likewise.
* ubsan/Makefile.in: Likewise.
---
 libsanitizer/asan/Makefile.am | 2 +-
 libsanitizer/asan/Makefile.in | 2 +-
 libsanitizer/hwasan/Makefile.am   | 2 +-
 libsanitizer/hwasan/Makefile.in   | 2 +-
 libsanitizer/interception/Makefile.am | 2 +-
 libsanitizer/interception/Makefile.in | 2 +-
 libsanitizer/lsan/Makefile.am | 2 +-
 libsanitizer/lsan/Makefile.in | 2 +-
 libsanitizer/sanitizer_common/Makefile.am | 2 +-
 libsanitizer/sanitizer_common/Makefile.in | 2 +-
 libsanitizer/tsan/Makefile.am | 2 +-
 libsanitizer/tsan/Makefile.in | 2 +-
 libsanitizer/ubsan/Makefile.am| 2 +-
 libsanitizer/ubsan/Makefile.in| 2 +-
 14 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/libsanitizer/asan/Makefile.am b/libsanitizer/asan/Makefile.am
index 4f802f723d6..7270116cf71 100644
--- a/libsanitizer/asan/Makefile.am
+++ b/libsanitizer/asan/Makefile.am
@@ -7,7 +7,7 @@ DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D
 if USING_MAC_INTERPOSE
 DEFS += -DMAC_INTERPOSE_FUNCTIONS -DMISSING_BLOCKS_SUPPORT
 endif
-AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic 
-Wno-long-long  -fPIC -fno-builtin -fno-exceptions -fno-rtti 
-fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros 
-fno-ipa-icf
+AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-long-long  
-fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer 
-funwind-tables -fvisibility=hidden -Wno-variadic-macros -fno-ipa-icf
 AM_CXXFLAGS += $(LIBSTDCXX_RAW_CXX_CXXFLAGS)
 AM_CXXFLAGS += -std=gnu++14
 AM_CXXFLAGS += $(EXTRA_CXXFLAGS)
diff --git a/libsanitizer/asan/Makefile.in b/libsanitizer/asan/Makefile.in
index 528ab61312c..26971051b82 100644
--- a/libsanitizer/asan/Makefile.in
+++ b/libsanitizer/asan/Makefile.in
@@ -416,7 +416,7 @@ AM_CPPFLAGS = -I $(top_srcdir)/include -I $(top_srcdir)
 
 # May be used by toolexeclibdir.

 gcc_version := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER)
-AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic \
+AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings \
-Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti \
-fomit-frame-pointer -funwind-tables -fvisibility=hidden \
-Wno-variadic-macros -fno-ipa-icf \
diff --git a/libsanitizer/hwasan/Makefile.am b/libsanitizer/hwasan/Makefile.am
index e12c0a0ce71..9fd39953789 100644
--- a/libsanitizer/hwasan/Makefile.am
+++ b/libsanitizer/hwasan/Makefile.am
@@ -4,7 +4,7 @@ AM_CPPFLAGS = -I $(top_srcdir)/include -I $(top_srcdir)
 gcc_version := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER)
 
 DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DCAN_SANITIZE_UB=0 -DHWASAN_WITH_INTERCEPTORS=1

-AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic 
-Wno-long-long  -fPIC -fno-builtin -fno-exceptions -fno-rtti -funwind-tables 
-fvisibility=hidden -Wno-variadic-macros -fno-ipa-icf
+AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-long-long  
-fPIC -fno-builtin -fno-exceptions -fno-rtti -funwind-tables 
-fvisibility=hidden -Wno-variadic-macros -fno-ipa-icf
 AM_CXXFLAGS += $(LIBSTDCXX_RAW_CXX_CXXFLAGS)
 AM_CXXFLAGS += -std=gnu++14
 AM_CXXFLAGS += $(EXTRA_CXXFLAGS)
diff --git 

Re: [PATCH] libsanitizer: merge from master (c86b4503a94c277534ce4b9a5c015a6ac151b98a).

2021-11-04 Thread Martin Liška

On 11/4/21 13:37, Jakub Jelinek wrote:

On Thu, Nov 04, 2021 at 01:25:43PM +0100, Martin Liška wrote:

diff --git a/libsanitizer/asan/asan_mapping.h b/libsanitizer/asan/asan_mapping.h
index 4b0037fced3..e5a7f2007ae 100644
--- a/libsanitizer/asan/asan_mapping.h
+++ b/libsanitizer/asan/asan_mapping.h
@@ -165,7 +165,7 @@ static const u64 kAArch64_ShadowOffset64 = 1ULL << 36;
  static const u64 kRiscv64_ShadowOffset64 = 0xd;
  static const u64 kMIPS32_ShadowOffset32 = 0x0aaa;
  static const u64 kMIPS64_ShadowOffset64 = 1ULL << 37;
-static const u64 kPPC64_ShadowOffset64 = 1ULL << 41;
+static const u64 kPPC64_ShadowOffset64 = 1ULL << 44;
  static const u64 kSystemZ_ShadowOffset64 = 1ULL << 52;
  static const u64 kSPARC64_ShadowOffset64 = 1ULL << 43;  // 0x800
  static const u64 kFreeBSD_ShadowOffset32 = 1ULL << 30;  // 0x4000


This looks wrong.
If anything, rs6000.c still has:
static unsigned HOST_WIDE_INT
rs6000_asan_shadow_offset (void)
{
   return (unsigned HOST_WIDE_INT) 1 << (TARGET_64BIT ? 41 : 29);
}
but just blindly changing it doesn't look a good idea, I vaguely remember
issues with this in the past.  I think ppc64 has various virtual address
space sizes and trying to find one that works with all of them is hard.

Jakub



This one is fixed in apply local patches revision:
65ade6a34cb62f82494c0a8ca4ff3600f3a94af9

Cheers,
Martin


  1   2   >