public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* Undelivered Mail Returned to Sender
@ 2021-08-10 21:15 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 21:15 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx408.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 465 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 14076 bytes --]

From: Fangrui Song via Libc-alpha <libc-alpha@sourceware.org>
To: libc-alpha@sourceware.org, Adhemerval Zanella <adhemerval.zanella@linaro.org>, Szabolcs Nagy <nsz@port70.net>
Subject: Re: [PATCH v2] aarch64: Skip traditional GD/LD TLS which are unsupported by Clang and LLD [BZ #28205]
Date: Tue, 10 Aug 2021 14:14:58 -0700
Message-ID: <20210810211458.oxx3t5phzt3z3sp3@google.com>

On 2021-08-10, Fangrui Song wrote:
>TLSDESC is the default on aarch64.  Clang doesn't support
>-mtls-dialect=trad.  Its integrated assembler doesn't support the
>marker.  LLD's doesn't support R_AARCH64_TLSGD_*/R_AARCH64_TLSLD_*
>relocations.  Just skip the tests.
>
>With https://sourceware.org/pipermail/libc-alpha/2021-August/129966.html
>("aarch64: Make elf_machine_{load_address, dynamic} robust [BZ #28203]"),
>if we allow LLD in configure.ac,
>`make check` test results of LLD are on par with GNU ld.

I messed up in the diff.
The correct diff needs `#include <config.h>` to make HAVE_TRAD_TLS
defined.

---
  config.h.in                  |  3 +++
  elf/tst-tls1.c               |  8 ++++++--
  elf/tst-tls2.c               |  7 +++++--
  elf/tst-tls3.c               |  9 +++++----
  elf/tst-tlsmod1.c            |  7 +++++--
  elf/tst-tlsmod2.c            |  5 ++++-
  elf/tst-tlsmod3.c            |  6 +++++-
  elf/tst-tlsmod4.c            |  5 ++++-
  sysdeps/aarch64/configure    | 30 ++++++++++++++++++++++++++++++
  sysdeps/aarch64/configure.ac | 18 ++++++++++++++++++
  10 files changed, 85 insertions(+), 13 deletions(-)

diff --git a/config.h.in b/config.h.in
index 0d92504f65..7dcce4d3a4 100644
--- a/config.h.in
+++ b/config.h.in
@@ -198,6 +198,9 @@
  /* Define if CC supports attribute retain.  */
  #undef HAVE_GNU_RETAIN
  
+/* Define if CC and LD support traditional TLS GD/LD models.  */
+#define HAVE_TRAD_TLS 1
+
  /* Define to 1 if the assembler needs intermediate aliases to define
     multiple symbol versions for one symbol.  */
  #define SYMVER_NEEDS_ALIAS 0
diff --git a/elf/tst-tls1.c b/elf/tst-tls1.c
index c31da56ce9..1f102b62b7 100644
--- a/elf/tst-tls1.c
+++ b/elf/tst-tls1.c
@@ -1,4 +1,5 @@
  /* glibc test for TLS in ld.so.  */
+#include <config.h>
  #include <stdio.h>
  
  #include "tls-macros.h"
@@ -39,7 +40,8 @@ do_test (void)
        result = 1;
      }
  
-
+  /* Clang and LLD do not support traditional GD/LD TLS on aarch64. */
+#if HAVE_TRAD_TLS
    /* Get variables using local dynamic model.  */
    fputs ("get sum of foo and bar (LD)", stdout);
    ap = TLS_LD (foo);
@@ -56,8 +58,9 @@ do_test (void)
        printf ("bar = %d\n", *bp);
        result = 1;
      }
+#endif
  
-
+#if HAVE_TRAD_TLS
    /* Get variables using generic dynamic model.  */
    fputs ("get sum of foo and bar (GD)", stdout);
    ap = TLS_GD (foo);
@@ -74,6 +77,7 @@ do_test (void)
        printf ("bar = %d\n", *bp);
        result = 1;
      }
+#endif
  
    return result;
  }
diff --git a/elf/tst-tls2.c b/elf/tst-tls2.c
index 963b8d6c88..46e69b049b 100644
--- a/elf/tst-tls2.c
+++ b/elf/tst-tls2.c
@@ -1,4 +1,5 @@
  /* glibc test for TLS in ld.so.  */
+#include <config.h>
  #include <stdio.h>
  
  #include "tls-macros.h"
@@ -39,7 +40,7 @@ do_test (void)
        result = 1;
      }
  
-
+#if HAVE_TRAD_TLS
    /* Get variables using local dynamic model.  */
    fputs ("get sum of foo and bar (LD)", stdout);
    ap = TLS_LD (foo);
@@ -56,8 +57,9 @@ do_test (void)
        printf ("bar = %d\n", *bp);
        result = 1;
      }
+#endif
  
-
+#if HAVE_TRAD_TLS
    /* Get variables using generic dynamic model.  */
    fputs ("get sum of foo and bar (GD)", stdout);
    ap = TLS_GD (foo);
@@ -74,6 +76,7 @@ do_test (void)
        printf ("bar = %d\n", *bp);
        result = 1;
      }
+#endif
  
    return result;
  }
diff --git a/elf/tst-tls3.c b/elf/tst-tls3.c
index 7e0abb4c58..4abdec2857 100644
--- a/elf/tst-tls3.c
+++ b/elf/tst-tls3.c
@@ -1,4 +1,5 @@
  /* glibc test for TLS in ld.so.  */
+#include <config.h>
  #include <stdio.h>
  
  #include "tls-macros.h"
@@ -17,8 +18,7 @@ static int
  do_test (void)
  {
    int result = 0;
-  int *ap, *bp, *cp;
-
+  int *ap, *bp;
  
    /* Set the variable using the local exec model.  */
    puts ("set baz to 3 (LE)");
@@ -33,7 +33,8 @@ do_test (void)
    bp = TLS_IE (bar);
    *bp = 2;
  
-
+#if HAVE_TRAD_TLS
+  int *cp;
    /* Get variables using local dynamic model.  */
    fputs ("get sum of foo, bar (GD) and baz (LD)", stdout);
    ap = TLS_GD (foo);
@@ -56,7 +57,7 @@ do_test (void)
        printf ("baz = %d\n", *cp);
        result = 1;
      }
-
+#endif
  
    result |= in_dso ();
  
diff --git a/elf/tst-tlsmod1.c b/elf/tst-tlsmod1.c
index 8d9156791b..94346415c3 100644
--- a/elf/tst-tlsmod1.c
+++ b/elf/tst-tlsmod1.c
@@ -1,3 +1,4 @@
+#include <config.h>
  #include <stdio.h>
  
  #include "tls-macros.h"
@@ -14,7 +15,7 @@ int
  in_dso (void)
  {
    int result = 0;
-  int *ap, *bp, *cp;
+  int *ap, *bp;
  
    /* Get variables using initial exec model.  */
    fputs ("get sum of foo and bar (IE)", stdout);
@@ -34,7 +35,8 @@ in_dso (void)
        result = 1;
      }
  
-
+#if HAVE_TRAD_TLS
+  int *cp;
    /* Get variables using generic dynamic model.  */
    fputs ("get sum of foo and bar and baz (GD)", stdout);
    ap = TLS_GD (foo);
@@ -57,6 +59,7 @@ in_dso (void)
        printf ("baz = %d\n", *cp);
        result = 1;
      }
+#endif
  
    return result;
  }
diff --git a/elf/tst-tlsmod2.c b/elf/tst-tlsmod2.c
index 40eb1407f8..8028237155 100644
--- a/elf/tst-tlsmod2.c
+++ b/elf/tst-tlsmod2.c
@@ -1,3 +1,4 @@
+#include <config.h>
  #include <stdio.h>
  
  #include "tls-macros.h"
@@ -9,9 +10,10 @@ COMMON_INT_DEF(foo);
  int
  in_dso (int n, int *caller_foop)
  {
-  int *foop;
    int result = 0;
  
+#if HAVE_TRAD_TLS
+  int *foop;
    puts ("foo");			/* Make sure PLT is used before macros.  */
    asm ("" ::: "memory");
  
@@ -29,6 +31,7 @@ in_dso (int n, int *caller_foop)
      }
  
    *foop = 16;
+#endif
  
    return result;
  }
diff --git a/elf/tst-tlsmod3.c b/elf/tst-tlsmod3.c
index 6d186c47ee..d001778247 100644
--- a/elf/tst-tlsmod3.c
+++ b/elf/tst-tlsmod3.c
@@ -1,3 +1,4 @@
+#include <config.h>
  #include <stdio.h>
  
  #include "tls-macros.h"
@@ -12,8 +13,10 @@ COMMON_INT_DEF(comm_n);
  int
  in_dso2 (void)
  {
-  int *foop;
    int result = 0;
+
+#if HAVE_TRAD_TLS
+  int *foop;
    static int n;
    int *np;
  
@@ -32,6 +35,7 @@ in_dso2 (void)
    result |= in_dso (*foop = 42 + n++, foop);
  
    *foop = 16;
+#endif
  
    return result;
  }
diff --git a/elf/tst-tlsmod4.c b/elf/tst-tlsmod4.c
index 86889aac7e..a31c163ca6 100644
--- a/elf/tst-tlsmod4.c
+++ b/elf/tst-tlsmod4.c
@@ -1,3 +1,4 @@
+#include <config.h>
  #include <stdio.h>
  
  #include "tls-macros.h"
@@ -9,9 +10,10 @@ COMMON_INT_DEF(baz);
  int
  in_dso (int n, int *caller_bazp)
  {
-  int *bazp;
    int result = 0;
  
+#if HAVE_TRAD_TLS
+  int *bazp;
    puts ("foo");			/* Make sure PLT is used before macros.  */
    asm ("" ::: "memory");
  
@@ -29,6 +31,7 @@ in_dso (int n, int *caller_bazp)
      }
  
    *bazp = 16;
+#endif
  
    return result;
  }
diff --git a/sysdeps/aarch64/configure b/sysdeps/aarch64/configure
index 4c1fac49f3..eb62e68010 100644
--- a/sysdeps/aarch64/configure
+++ b/sysdeps/aarch64/configure
@@ -332,3 +332,33 @@ if test $libc_cv_aarch64_sve_asm = yes; then
    $as_echo "#define HAVE_AARCH64_SVE_ASM 1" >>confdefs.h
  
  fi
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for -mtls-dialect=trad" >&5
+$as_echo_n "checking for -mtls-dialect=trad... " >&6; }
+if ${libc_cv_aarch64_trad_tls+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  cat > conftest.c <<EOF
+extern __thread int i;
+void foo (void) { i = 10; }
+EOF
+  if { ac_try='${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS -fPIC
+                     -mtls-dialect=trad -shared -o conftest.so conftest.c'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; }
+  then
+    libc_cv_aarch64_trad_tls=yes
+  else
+    libc_cv_aarch64_trad_tls=no
+  fi
+  rm -f conftest*
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_aarch64_trad_tls" >&5
+$as_echo "$libc_cv_aarch64_trad_tls" >&6; }
+if test $libc_cv_aarch64_trad_tls = no; then
+  $as_echo "#define HAVE_TRAD_TLS 0" >>confdefs.h
+
+fi
diff --git a/sysdeps/aarch64/configure.ac b/sysdeps/aarch64/configure.ac
index 3347c13fa1..6d3b412acc 100644
--- a/sysdeps/aarch64/configure.ac
+++ b/sysdeps/aarch64/configure.ac
@@ -105,3 +105,21 @@ rm -f conftest*])
  if test $libc_cv_aarch64_sve_asm = yes; then
    AC_DEFINE(HAVE_AARCH64_SVE_ASM)
  fi
+
+# Check if both CC and LD support traditional TLS GD/LD models.
+AC_CACHE_CHECK([for -mtls-dialect=trad], libc_cv_aarch64_trad_tls, [dnl
+cat > conftest.c <<EOF
+extern __thread int i;
+void foo (void) { i = 10; }
+EOF
+  if AC_TRY_COMMAND([${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS -fPIC
+                     -mtls-dialect=trad -shared -o conftest.so conftest.c])
+  then
+    libc_cv_aarch64_trad_tls=yes
+  else
+    libc_cv_aarch64_trad_tls=no
+  fi
+  rm -f conftest*])
+if test $libc_cv_aarch64_trad_tls = no; then
+  AC_DEFINE(HAVE_TRAD_TLS, 0)
+fi
-- 
2.32.0.605.g8dce9f2422-goog



To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=cf44.6112ec73.9d192.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+%5BPATCH+v2%5D+aarch64%3A+Skip+traditional+GD%2FLD+TLS+which+are+unsupported+by+Clang+and+LLD+%5BBZ+%2328205%5D&verdict=C&c=8364eee59d11c472fa78f93471905545234abf19

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-11  0:54 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-11  0:54 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx405.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 464 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 9672 bytes --]

From: Ian Kent via Libc-alpha <libc-alpha@sourceware.org>
To: "Binello, Severino" <sev@bnl.gov>, libc-alpha@sourceware.org, fweimer@redhat.com, "Marusic, Aljosa" <marusic@bnl.gov>
Subject: Re: Building sunrpc from glibc source
Date: Wed, 11 Aug 2021 08:53:36 +0800
Message-ID: <8e080640-21f1-5da3-3617-2a137faf54cb@redhat.com>


On 11/8/21 1:47 am, Binello, Severino wrote:
> Hello Ian and Florian
>
> Thanks for the feedback, its much appreciated
> Unfortunately Im not the best person to be asking the questions or 
> providing the info
> My role with our communication code right now is to get it to build
>
> I am reaching out to the developer of our rpc based code to see if he 
> can provide
> a better picture and provide  further information.
> So I am including Al Marusic in this email thread.


Ok.


Don't get me wrong, I do understand the potential difficulty changing

to libtirpc.


But glibc rpc has been on the chopping block for years so there's been

plenty of time to investigate and change.


At the very least some analysis needs to be done about the application

rpc usage to understand where the difficulties are.


Certainly, if you use low level rpc calls (in order to take control of

timeouts and such) the work would be substantial but if your using higher

level rpc calls it might not be so bad.


TBH the application I maintain does need to use lower level rpc calls so

using libtirpc was a significant change for me, but that was a long time

ago now.


Bottom line is that libtirpc is thread safe but it depends on the rpc

calls that are used.


Ian

>
> Thanks again!
> -Sev
>
> ------------------------------------------------------------------------
> *From:* Ian Kent <ikent@redhat.com>
> *Sent:* Friday, August 6, 2021 8:27 PM
> *To:* Binello, Severino <sev@bnl.gov>; libc-alpha@sourceware.org 
> <libc-alpha@sourceware.org>
> *Subject:* Re: Building sunrpc from glibc source
>
> On 6/8/21 8:07 pm, Ian Kent wrote:
> > On 6/8/21 7:12 am, Binello, Severino via Libc-alpha wrote:
> >> Hello
> >>
> >>    As of RedHat 8, the sunrpc is no longer included with glibc shared
> >> object library.
> >> Unfortunately, our communications software would require extensive
> >> redesign in order to use tirpc.
> >
> > For example?
> >
> > Can you describe the sort of challenges you have doing this please.
> >
> >
> >> As such, we are looking into an alternative approach where we just
> >> build the sunrpc portion from the glibc source tar file.
> >> However, running into difficulties separating it out.
> >> Can you recommend a method for just building the sunrpc code ?
> >
> > It's worth understanding what might be needed in order to use libtirpc
> >
> > first.
> >
> >
> >>
> >> Thanks Much
> >> -Sev
> >>
> >> ps: Below is the reason why our code is incompatible with the tirpc
> >> design
> >> with old glibc every RPC server runs in its own thread,
> >> with tirpc library there can be only one RPC server per program.
> >> See:
> >> from svc.c of tirpc library:
> >>
> >> static struct svc_callout /* removed declaration */ *svc_head;
> >>
> >> from svc.c of glibc-2.25:
> >>
> >> #ifdef _RPC_THREAD_SAFE_
> >> #define svc_head RPC_THREAD_VARIABLE(svc_head_s)
> >> #else
> >> static struct svc_callout *svc_head;
> >> #endif
> >>
> >> As you can see, if RPC_THREAD_SAFE_ is defined,
> >> svc_head is per thread variable.
> >
> > I think I have some quick and nasty multi-thread libtirpc svc code
> >
> > kicking around somewhere (if I can find it now). It might be worth
> >
> > cleaning that up and maybe enhancing it a little, or maybe it's broken
> >
> > I don't know, but I'd recommend looking at that first, if there's not
> >
> > to many other problems to deal with.
>
> Actually it looks like this was multi-threaded io not multi-threaded
> servers.
>
>
> But I'm not sure that you can't register multiple services in both glibc
>
> and libtirpc, it's just that it's not thread safe to do so in glibc.
>
>
> Maybe I don't understand what your doing, explain it please.
>
>
> Why do you need a separate services list for each thread rather than a
>
> library global lock protected services list as in libtirpc?
>
>
> Ian
>


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=159c2.61131fac.6ff3b.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+Building+sunrpc+from+glibc+source&verdict=C&c=0198a7272b86f871dfb7eb689d2f929c9aeddf13

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 22:34 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 22:34 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx304.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 463 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 5080 bytes --]

From: Fangrui Song via Libc-alpha <libc-alpha@sourceware.org>
To: libc-alpha@sourceware.org
Subject: ChangeLog on wiki contribution checklist
Date: Tue, 10 Aug 2021 15:34:09 -0700
Message-ID: <20210810223409.bqra4lxhmxky4gdx@google.com>

Now that ChangeLog is not required, the two wiki pages may need updates.

https://sourceware.org/glibc/wiki/GlibcGit#ChangeLogs
https://sourceware.org/glibc/wiki/Committer%20checklist#Update_The_ChangeLog_File
   (https://sourceware.org/glibc/wiki/Contribution%20checklist does not mention ChangeLog)


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=c255.6112feff.c70cc.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=ChangeLog+on+wiki+contribution+checklist&verdict=C&c=116ed85c4f3adafa37024aea5f28e925ca7e2af9

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 22:19 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 22:19 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx408.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 465 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 6895 bytes --]

From: Fangrui Song via Libc-alpha <libc-alpha@sourceware.org>
To: libc-alpha@sourceware.org
Subject: Re: [PATCH v2 3/3] configure: Allow LD to be LLD 13.0.0 or above [BZ #26558]
Date: Tue, 10 Aug 2021 15:19:15 -0700
Message-ID: <20210810221915.g6ipyceykaio3324@google.com>

On 2021-08-05, Fangrui Song wrote:
>When using LLD (LLVM linker) as the linker, configure prints a confusing
>message.
>
>    *** These critical programs are missing or too old: GNU ld
>
>LLD>=13.0.0 can build glibc --enable-static-pie. (8.0.0 needs one
>workaround for -Wl,-defsym=_begin=0. 9.0.0 works with
>--disable-static-pie).
>
>With BZ #28153 (glibc bug exposed by testing with LLD) fixed,
>`make check` only has 2 more failures with LLD than with GNU ld:
>BZ #28154 (LLD follows the PowerPC port of GNU ld for ifunc by
>placing IRELATIVE relocations in .rela.dyn).
>The set of dynamic symbols is the same with GNU ld and LLD,
>modulo unused SHN_ABS version node symbols.
>
>For comparison, gold does not support --enable-static-pie
>yet (--no-dynamic-linker is unsupported BZ #22221), yet
>has 6 failures more than LLD. gold linked libc.so has
>larger .dynsym differences with GNU ld and LLD
>(ISTM non-default version symbols are changed to default versions
>by a version script).
>
>---
>
>I identified the lack of support of
>
>* version script on non-default version symbols
>* copy relocations on non-default version symbols
>
>in an earlier snapshot of LLD 13.0.0 and fixed them.
>The functionality of the LLD linked libc.so and ld.so looks pretty good.
>---
> configure    | 77 +++++++++++++++++++++++++++++++++++++++++++++++++---
> configure.ac | 20 ++++++++++----
> 2 files changed, 88 insertions(+), 9 deletions(-)

Ping:)

(The code/test hasn't been changed since v1.
  v2 just added BZ numbers.)

x86-64 only 2 more ifunc FAIL which tickle some weak point of ifunc implementation.

aarch64 `make-check` is fully on par with GNU ld.
   (https://sourceware.org/pipermail/libc-alpha/2021-August/130040.html)


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=17c71.6112fb88.2eb99.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+%5BPATCH+v2+3%2F3%5D+configure%3A+Allow+LD+to+be+LLD+13.0.0+or+above+%5BBZ+%2326558%5D&verdict=C&c=fb2bf847fc021f4bc78191dbdd3da5b634132cc1

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 21:09 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 21:09 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx306.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 464 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Undelivered Message Headers --]
[-- Type: text/rfc822-headers, Size: 4990 bytes --]

Return-Path: <libc-alpha@sourceware.org>
Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) by
 fx306.security-mail.net (Postfix) with ESMTPS id CDCAB3993B6 for
 <mpoulhies@kalray.eu>; Tue, 10 Aug 2021 23:08:57 +0200 (CEST)
Received: from server2.sourceware.org (localhost [IPv6:::1]) by
 sourceware.org (Postfix) with ESMTP id D8D7F389F4FC for
 <mpoulhies@kalray.eu>; Tue, 10 Aug 2021 21:08:56 +0000 (GMT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com
 [IPv6:2607:f8b0:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id
 92054385C40C for <libc-alpha@sourceware.org>; Tue, 10 Aug 2021 21:08:32
 +0000 (GMT)
Received: by mail-pl1-x62d.google.com with SMTP id d1so23085703pll.1 for
 <libc-alpha@sourceware.org>; Tue, 10 Aug 2021 14:08:32 -0700 (PDT)
Received: from ?IPv6:2804:431:c7cb:9dce:5752:5b5a:453:cdda?
 ([2804:431:c7cb:9dce:5752:5b5a:453:cdda]) by smtp.gmail.com with ESMTPSA id
 21sm24804883pfh.103.2021.08.10.14.08.30 (version=TLS1_3
 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Aug 2021 14:08:31 -0700
 (PDT)
X-Quarantine-ID: <avzHAGirSY5a>
X-Virus-Scanned: E-securemail, by Secumail
X-Spam-Status: No, score=-2.286 tagged_above=-1000 required=7.5
 tests=[AB_ENVFROM_LONG_40=0.5, AB_IN_REPLY_TO_EXISTS=-1,
 AB_LONG_SUBJ_30=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-1, DKIM_VALID_AU=-0.1,
 FSL_RCVD_EX_4=0.01, FSL_RCVD_UT_4=0.01, HEAD_NEWS=-0.5, MISSING_MID=0.14,
 MM_ENVFROM_BOUNCE=1, NICE_REPLY_A=1, RCVD_IN_DNSWL_MED=-1.3,
 RDNS_DYNAMIC=0.363, S_FROM_GREY_MINUS_2=-2, S_KW_BODY__UPDATE_=0.5,
 T_RP_MATCHES_RCVD=-0.01] autolearn=disabled
Authentication-Results: fx306.security-mail.net (amavisd-new); dkim=pass
 (1024-bit key) header.d=sourceware.org
Secumail-id: <115e6.6112eae9.cb9bd.0>
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D8D7F389F4FC
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
 s=default; t=1628629736; bh=JXoz9ZRJFNx4XJkK9+c47pc17rX+jx++/VCGL6XgXu4=;
 h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe:
 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From;
 b=R5asBcM/ZDFcncIS545F+ywboQkmUo5PBrI5iYAuePn61NB/YZolb9rOGy4oXCcj4
 V7p0z0EgAOj/NKzOz/y5JmXDr0faRsZyGhu13N/RkWQKNa0uYxu8cABLo0ZeBr2GJL
 RbfGEo7W7mEIzL9g+KSdR0eOhlCRnt+SrIZI/tvY=
X-Original-To: libc-alpha@sourceware.org
Delivered-To: libc-alpha@sourceware.org
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 92054385C40C
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net;
 s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date
 :user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding; bh=JXoz9ZRJFNx4XJkK9+c47pc17rX+jx++/VCGL6XgXu4=;
 b=ohwPVTTBuN7Qh05smq8uK5GK/ZyxIXSox0ibkPBu1E54lsZEpvsbtYT7HraP1s+RcV
 pWDicfIvbvC5nWpLmx580Nm7LI1avkg1VkQ95QgV3p6TXTl9LrI1rhTKW2r/i3TRwiHR
 drDBIOcynLlJzIEddiC16d9og4skEpFeLns8nzxK7NLIsPaAv+IAGwJNaua18K18Wi8g
 234nJM4LnviwdDXL41pt65DlRLtwIODLOM8Qsz1rXiOAWucbs0NzNP0NLgqJkfXigke8
 A3jamBC4SJ6yvdSePWMBse8KRXNTUnRmJcJ8kiC2vLij1etWb62GDtH/yATK3ZONiOTZ CKoQ==
X-Gm-Message-State: AOAM533L1dnsnX6sM39979KbNKW9dAfnCjIqufKCT42LWuhwuvCs0KGz
 7MfVNpxulhf8sAgiCBiaOLJnWA==
X-Google-Smtp-Source: ABdhPJzuwpZUJr+xyZxuqCfEjBzQ0adedMN9LFjeR1VYHP6t2O/7n7srRAxuJrU2O3mlTn7fFE64wg==
X-Received: by 2002:a17:90a:df14:: with SMTP id
 gp20mr4719974pjb.33.1628629711512;  Tue, 10 Aug 2021 14:08:31 -0700 (PDT)
Subject: Re: [PATCH v6 2/2] BZ #17645, fix slow DSO sorting behavior in
 dynamic loader -- Algorithm changes
To: Chung-Lin Tang <cltang@codesourcery.com>, GNU C Library
 <libc-alpha@sourceware.org>, Florian Weimer <fweimer@redhat.com>
References: <30aa9fbd-fc08-9a6f-d34b-accb47abd8af@codesourcery.com>
Message-ID: <334c6848-e805-4666-add5-e611f1d7c255@linaro.org>
Date: Tue, 10 Aug 2021 18:08:28 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <30aa9fbd-fc08-9a6f-d34b-accb47abd8af@codesourcery.com>
Content-Language: en-us
X-BeenThere: libc-alpha@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=subscribe>
From: Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org>
Reply-To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Errors-To: libc-alpha-bounces+mpoulhies=kalray.eu@sourceware.org
Sender: Libc-alpha <libc-alpha-bounces+mpoulhies=kalray.eu@sourceware.org>
Content-Type: multipart/alternative; boundary="=_VSfH-gNOPvHsw3MxAnKnV7d"
X-ALTERMIMEV2_in: done
Content-Transfer-Encoding: 8bit

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 21:03 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 21:03 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx306.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 464 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 12754 bytes --]

From: Fangrui Song via Libc-alpha <libc-alpha@sourceware.org>
To: libc-alpha@sourceware.org, Adhemerval Zanella <adhemerval.zanella@linaro.org>, Szabolcs Nagy <nsz@port70.net>
Subject: [PATCH v2] aarch64: Skip traditional GD/LD TLS which are unsupported by Clang and LLD [BZ #28205]
Date: Tue, 10 Aug 2021 14:02:47 -0700
Message-ID: <20210810210247.676100-1-maskray@google.com>

TLSDESC is the default on aarch64.  Clang doesn't support
-mtls-dialect=trad.  Its integrated assembler doesn't support the
marker.  LLD's doesn't support R_AARCH64_TLSGD_*/R_AARCH64_TLSLD_*
relocations.  Just skip the tests.

With https://sourceware.org/pipermail/libc-alpha/2021-August/129966.html
("aarch64: Make elf_machine_{load_address, dynamic} robust [BZ #28203]"),
if we allow LLD in configure.ac,
`make check` test results of LLD are on par with GNU ld.
---
 config.h.in                  |  3 +++
 elf/tst-tls1.c               |  7 +++++--
 elf/tst-tls2.c               |  6 ++++--
 elf/tst-tls3.c               |  8 ++++----
 elf/tst-tlsmod1.c            |  6 ++++--
 elf/tst-tlsmod2.c            |  4 +++-
 elf/tst-tlsmod3.c            |  5 ++++-
 elf/tst-tlsmod4.c            |  4 +++-
 sysdeps/aarch64/configure    | 30 ++++++++++++++++++++++++++++++
 sysdeps/aarch64/configure.ac | 18 ++++++++++++++++++
 10 files changed, 78 insertions(+), 13 deletions(-)

diff --git a/config.h.in b/config.h.in
index 0d92504f65..7dcce4d3a4 100644
--- a/config.h.in
+++ b/config.h.in
@@ -198,6 +198,9 @@
 /* Define if CC supports attribute retain.  */
 #undef HAVE_GNU_RETAIN
 
+/* Define if CC and LD support traditional TLS GD/LD models.  */
+#define HAVE_TRAD_TLS 1
+
 /* Define to 1 if the assembler needs intermediate aliases to define
    multiple symbol versions for one symbol.  */
 #define SYMVER_NEEDS_ALIAS 0
diff --git a/elf/tst-tls1.c b/elf/tst-tls1.c
index c31da56ce9..57d5ea2485 100644
--- a/elf/tst-tls1.c
+++ b/elf/tst-tls1.c
@@ -39,7 +39,8 @@ do_test (void)
       result = 1;
     }
 
-
+  /* Clang and LLD do not support traditional GD/LD TLS on aarch64. */
+#ifdef HAVE_TRAD_TLS
   /* Get variables using local dynamic model.  */
   fputs ("get sum of foo and bar (LD)", stdout);
   ap = TLS_LD (foo);
@@ -56,8 +57,9 @@ do_test (void)
       printf ("bar = %d\n", *bp);
       result = 1;
     }
+#endif
 
-
+#ifdef HAVE_TRAD_TLS
   /* Get variables using generic dynamic model.  */
   fputs ("get sum of foo and bar (GD)", stdout);
   ap = TLS_GD (foo);
@@ -74,6 +76,7 @@ do_test (void)
       printf ("bar = %d\n", *bp);
       result = 1;
     }
+#endif
 
   return result;
 }
diff --git a/elf/tst-tls2.c b/elf/tst-tls2.c
index 963b8d6c88..c9dcc084e3 100644
--- a/elf/tst-tls2.c
+++ b/elf/tst-tls2.c
@@ -39,7 +39,7 @@ do_test (void)
       result = 1;
     }
 
-
+#ifdef HAVE_TRAD_TLS
   /* Get variables using local dynamic model.  */
   fputs ("get sum of foo and bar (LD)", stdout);
   ap = TLS_LD (foo);
@@ -56,8 +56,9 @@ do_test (void)
       printf ("bar = %d\n", *bp);
       result = 1;
     }
+#endif
 
-
+#ifdef HAVE_TRAD_TLS
   /* Get variables using generic dynamic model.  */
   fputs ("get sum of foo and bar (GD)", stdout);
   ap = TLS_GD (foo);
@@ -74,6 +75,7 @@ do_test (void)
       printf ("bar = %d\n", *bp);
       result = 1;
     }
+#endif
 
   return result;
 }
diff --git a/elf/tst-tls3.c b/elf/tst-tls3.c
index 7e0abb4c58..6f2e144a7f 100644
--- a/elf/tst-tls3.c
+++ b/elf/tst-tls3.c
@@ -17,8 +17,7 @@ static int
 do_test (void)
 {
   int result = 0;
-  int *ap, *bp, *cp;
-
+  int *ap, *bp;
 
   /* Set the variable using the local exec model.  */
   puts ("set baz to 3 (LE)");
@@ -33,7 +32,8 @@ do_test (void)
   bp = TLS_IE (bar);
   *bp = 2;
 
-
+#ifdef HAVE_TRAD_TLS
+  int *cp;
   /* Get variables using local dynamic model.  */
   fputs ("get sum of foo, bar (GD) and baz (LD)", stdout);
   ap = TLS_GD (foo);
@@ -56,7 +56,7 @@ do_test (void)
       printf ("baz = %d\n", *cp);
       result = 1;
     }
-
+#endif
 
   result |= in_dso ();
 
diff --git a/elf/tst-tlsmod1.c b/elf/tst-tlsmod1.c
index 8d9156791b..9f48e36af4 100644
--- a/elf/tst-tlsmod1.c
+++ b/elf/tst-tlsmod1.c
@@ -14,7 +14,7 @@ int
 in_dso (void)
 {
   int result = 0;
-  int *ap, *bp, *cp;
+  int *ap, *bp;
 
   /* Get variables using initial exec model.  */
   fputs ("get sum of foo and bar (IE)", stdout);
@@ -34,7 +34,8 @@ in_dso (void)
       result = 1;
     }
 
-
+#ifdef HAVE_TRAD_TLS
+  int *cp;
   /* Get variables using generic dynamic model.  */
   fputs ("get sum of foo and bar and baz (GD)", stdout);
   ap = TLS_GD (foo);
@@ -57,6 +58,7 @@ in_dso (void)
       printf ("baz = %d\n", *cp);
       result = 1;
     }
+#endif
 
   return result;
 }
diff --git a/elf/tst-tlsmod2.c b/elf/tst-tlsmod2.c
index 40eb1407f8..78578ebcc2 100644
--- a/elf/tst-tlsmod2.c
+++ b/elf/tst-tlsmod2.c
@@ -9,9 +9,10 @@ COMMON_INT_DEF(foo);
 int
 in_dso (int n, int *caller_foop)
 {
-  int *foop;
   int result = 0;
 
+#ifdef HAVE_TRAD_TLS
+  int *foop;
   puts ("foo");			/* Make sure PLT is used before macros.  */
   asm ("" ::: "memory");
 
@@ -29,6 +30,7 @@ in_dso (int n, int *caller_foop)
     }
 
   *foop = 16;
+#endif
 
   return result;
 }
diff --git a/elf/tst-tlsmod3.c b/elf/tst-tlsmod3.c
index 6d186c47ee..d9f17dbb6f 100644
--- a/elf/tst-tlsmod3.c
+++ b/elf/tst-tlsmod3.c
@@ -12,8 +12,10 @@ COMMON_INT_DEF(comm_n);
 int
 in_dso2 (void)
 {
-  int *foop;
   int result = 0;
+
+#ifdef HAVE_TRAD_TLS
+  int *foop;
   static int n;
   int *np;
 
@@ -32,6 +34,7 @@ in_dso2 (void)
   result |= in_dso (*foop = 42 + n++, foop);
 
   *foop = 16;
+#endif
 
   return result;
 }
diff --git a/elf/tst-tlsmod4.c b/elf/tst-tlsmod4.c
index 86889aac7e..27baaaf501 100644
--- a/elf/tst-tlsmod4.c
+++ b/elf/tst-tlsmod4.c
@@ -9,9 +9,10 @@ COMMON_INT_DEF(baz);
 int
 in_dso (int n, int *caller_bazp)
 {
-  int *bazp;
   int result = 0;
 
+#ifdef HAVE_TRAD_TLS
+  int *bazp;
   puts ("foo");			/* Make sure PLT is used before macros.  */
   asm ("" ::: "memory");
 
@@ -29,6 +30,7 @@ in_dso (int n, int *caller_bazp)
     }
 
   *bazp = 16;
+#endif
 
   return result;
 }
diff --git a/sysdeps/aarch64/configure b/sysdeps/aarch64/configure
index 4c1fac49f3..eb62e68010 100644
--- a/sysdeps/aarch64/configure
+++ b/sysdeps/aarch64/configure
@@ -332,3 +332,33 @@ if test $libc_cv_aarch64_sve_asm = yes; then
   $as_echo "#define HAVE_AARCH64_SVE_ASM 1" >>confdefs.h
 
 fi
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for -mtls-dialect=trad" >&5
+$as_echo_n "checking for -mtls-dialect=trad... " >&6; }
+if ${libc_cv_aarch64_trad_tls+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  cat > conftest.c <<EOF
+extern __thread int i;
+void foo (void) { i = 10; }
+EOF
+  if { ac_try='${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS -fPIC
+                     -mtls-dialect=trad -shared -o conftest.so conftest.c'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; }
+  then
+    libc_cv_aarch64_trad_tls=yes
+  else
+    libc_cv_aarch64_trad_tls=no
+  fi
+  rm -f conftest*
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_aarch64_trad_tls" >&5
+$as_echo "$libc_cv_aarch64_trad_tls" >&6; }
+if test $libc_cv_aarch64_trad_tls = no; then
+  $as_echo "#define HAVE_TRAD_TLS 0" >>confdefs.h
+
+fi
diff --git a/sysdeps/aarch64/configure.ac b/sysdeps/aarch64/configure.ac
index 3347c13fa1..6d3b412acc 100644
--- a/sysdeps/aarch64/configure.ac
+++ b/sysdeps/aarch64/configure.ac
@@ -105,3 +105,21 @@ rm -f conftest*])
 if test $libc_cv_aarch64_sve_asm = yes; then
   AC_DEFINE(HAVE_AARCH64_SVE_ASM)
 fi
+
+# Check if both CC and LD support traditional TLS GD/LD models.
+AC_CACHE_CHECK([for -mtls-dialect=trad], libc_cv_aarch64_trad_tls, [dnl
+cat > conftest.c <<EOF
+extern __thread int i;
+void foo (void) { i = 10; }
+EOF
+  if AC_TRY_COMMAND([${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS -fPIC
+                     -mtls-dialect=trad -shared -o conftest.so conftest.c])
+  then
+    libc_cv_aarch64_trad_tls=yes
+  else
+    libc_cv_aarch64_trad_tls=no
+  fi
+  rm -f conftest*])
+if test $libc_cv_aarch64_trad_tls = no; then
+  AC_DEFINE(HAVE_TRAD_TLS, 0)
+fi
-- 
2.32.0.605.g8dce9f2422-goog



To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=d57a.6112e9b4.74114.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=%5BPATCH+v2%5D+aarch64%3A+Skip+traditional+GD%2FLD+TLS+which+are+unsupported+by+Clang+and+LLD+%5BBZ+%2328205%5D&verdict=C&c=e4fe07cdc0ab59e4232debd4d94a7f6c99fe8682

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 20:11 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 20:11 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx301.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 465 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 15464 bytes --]

[-- Attachment #3.1.1: Type: text/plain, Size: 6315 bytes --]

On Tuesday 10 August 2021 21:49:28 Pali Rohár wrote:
> Setting custom baudrate for which is not defined Bnnn constant is possible
> via BOTHER flag and then filling speed in c_ospeed and c_ispeed fields.
> 
> These two fields are either in struct termios or struct termios2. Former
> belongs to TCGETS/TCSETS ioctls, latter to TCGETS2/TCSETS2 ioctls.
> 
> BOTHER flag with these two fields and new struct termios2 is not supported
> by older versions of include header files.
> 
> Some architectures (e.g. amd64) provide both struct termios and struct
> termios2, but c_ospeed and c_ispeed are only in struct termios2.
> 
> Some other architectures (e.g. alpha) provide both struct termios and struct
> termios2 and both have c_ospeed and c_ispeed fields.
> 
> And some other architectures (e.g. powerpc) provide only struct termios
> (no struct termios2) and it has c_ospeed and c_ispeed fields.
> 
> So basically to support all architectures it is needed to use
> struct termios2 when TCGETS2/TCSETS2 is supported. Otherwise it is needed
> to use struct termios with TCGETS/TCSETS (case for e.g. powerpc).
> 
> Setting input baudrate is done via IBSHIFT macro.
> 
> Signed-off-by: Pali Rohár <pali@kernel.org>
> 
> ---
> Changes in v4:
> * Add SPDX-License-Identifier
> * Correctly process split baudrates (separate output and input) via IBSHIFT
> * Update commit message
> 
> Changes in v3:
> * Check support for custom baudrate only based on BOTHER macro
> * Use TCGETS/TCSETS/termios when TCGETS2/TCSETS2/termios2 is not available
> 
> Changes in v2:
> * Use \e for backslash
> * Use exit(EXIT_*) instead of return num
> * Sort includes
> * Add comment about possible fallback
> ---
>  man2/ioctl_tty.2 | 100 +++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 100 insertions(+)
> 
> diff --git a/man2/ioctl_tty.2 b/man2/ioctl_tty.2
> index abfdc1e21fe9..7b2b03ff6757 100644
> --- a/man2/ioctl_tty.2
> +++ b/man2/ioctl_tty.2
> @@ -796,6 +796,106 @@ main(void)
>      close(fd);
>  }
>  .EE
> +.PP
> +Get or set arbitrary baudrate on the serial port.
> +.PP
> +.EX
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +
> +#include <asm/termbits.h>
> +#include <fcntl.h>
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <sys/ioctl.h>
> +#include <sys/types.h>
> +#include <unistd.h>
> +
> +int
> +main(int argc, char *argv[])
> +{
> +#ifndef BOTHER
> +    fprintf(stderr, "BOTHER is unsupported\en");
> +    /* Program may fallback to TCGETS/TCSETS with Bnnn constants */
> +    exit(EXIT_FAILURE);
> +#else
> +    /* Declare tio structure, its type depends on supported ioctl */
> +#ifdef TCGETS2
> +    struct termios2 tio;
> +#else
> +    struct termios tio;
> +#endif
> +    int fd, rc;
> +
> +    if (argc != 2 && argc != 3 && argc != 4) {
> +        fprintf(stderr, "Usage: %s device [output [input] ]\en", argv[0]);
> +        exit(EXIT_FAILURE);
> +    }
> +
> +    fd = open(argv[1], O_RDWR | O_NONBLOCK | O_NOCTTY);
> +    if (fd < 0) {
> +        perror("open");
> +        exit(EXIT_FAILURE);
> +    }
> +
> +    /* Get the current serial port settings via supported ioctl */
> +#ifdef TCGETS2
> +    rc = ioctl(fd, TCGETS2, &tio);
> +#else
> +    rc = ioctl(fd, TCGETS, &tio);
> +#endif
> +    if (rc) {
> +        perror("TCGETS");
> +        close(fd);
> +        exit(EXIT_FAILURE);
> +    }
> +
> +    /* Change baud rate when more arguments were provided */
> +    if (argc == 3 || argc == 4) {
> +        /* Clear the current output baud rate and fill a new value */
> +        tio.c_cflag &= ~CBAUD;
> +        tio.c_cflag |= BOTHER;
> +        tio.c_ospeed = atoi(argv[2]);
> +
> +        /* Clear the current input baud rate and fill a new value */
> +        tio.c_cflag &= ~(CBAUD << IBSHIFT);
> +        tio.c_cflag |= BOTHER << IBSHIFT;
> +        /* When 4th argument is not provided reuse output baud rate */
> +        tio.c_ispeed = (argc == 4) ? atoi(argv[3]) : atoi(argv[2]);
> +
> +        /* Set new serial port settings via supported ioctl */
> +#ifdef TCSETS2
> +        rc = ioctl(fd, TCSETS2, &tio);
> +#else
> +        rc = ioctl(fd, TCSETS, &tio);
> +#endif
> +        if (rc) {
> +            perror("TCSETS");
> +            close(fd);
> +            exit(EXIT_FAILURE);
> +        }
> +
> +        /* And get new values which were really configured */
> +#ifdef TCGETS2
> +        rc = ioctl(fd, TCGETS2, &tio);
> +#else
> +        rc = ioctl(fd, TCGETS, &tio);
> +#endif
> +        if (rc) {
> +            perror("TCGETS");
> +            close(fd);
> +            exit(EXIT_FAILURE);
> +        }
> +    }
> +
> +    close(fd);
> +
> +    printf("output baud rate: %u\en", tio.c_ospeed);
> +    printf("input baud rate: %u\en", tio.c_ispeed);
> +
> +    exit(EXIT_SUCCESS);
> +#endif
> +}
> +.EE
>  .SH SEE ALSO
>  .BR ldattach (1),
>  .BR ioctl (2),
> -- 
> 2.20.1
> 

Alejandro, in case you are interested I wrote also longer version which
can be compiled also with header files without BOTHER support.

I found out that because glibc does not support setting BOTHER speeds,
it also is not able to read current speed (via cfgetospeed()) if serial
port is configured to BOTHER state. And because lot of applications,
including GNU stty, use glibc's cfgetospeed() they are not able to parse
tty serial ports when BOTHER is set.

So due current glibc version, it is preferred to use Bnnn constants and
use BOTHER with c_ospeed only in case when there is no corresponding
Bnnn constant.

In this longer version, this preference is implemented.

But because this longer version is _longer_ I do not know if it is a
good idea to have it in manpage, even it is more preferred for
interoperability with existing applications.

Greg, if you have time, I would like to ask for reviewing new version
of manpage patch (or longer version). Or if you have an idea what is
better example in manpage (short or that longer version).

Longer version is below as MIME inline part of email.


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=f422.6112dd87.1ab57.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+%5BPATCH+v4%5D+ioctl_tty.2%3A+Add+example+how+to+get+or+set+baudrate+on+the+serial+port&verdict=C&c=2a04f3e116f2c58d060f7f046f656ae1604bf1c0

[-- Attachment #3.1.2: Type: text/x-csrc, Size: 4880 bytes --]

/* SPDX-FileCopyrightText: 2021 Pali Rohár <pali@kernel.org> */
/* SPDX-License-Identifier: GPL-2.0-or-later */

#include <asm/termbits.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <unistd.h>

#define B(n) { B##n, n }
static
struct { tcflag_t bn; unsigned int n; }
map[] =
{
    B(0), B(50), B(75), B(110), B(134), B(150), B(200), B(300), B(600),
    B(1200), B(1800), B(2400), B(4800), B(9600), B(19200), B(38400),
    B(57600), B(115200), B(230400), B(460800), B(500000), B(576000),
    B(921600), B(1000000), B(1152000), B(1500000), B(2000000),
#ifdef B2500000
    /* non-SPARC architectures support these Bnnn constants */
    B(2500000), B(3000000), B(3500000), B(4000000)
#else
    /* SPARC architecture supports these Bnnn constants */
    B(76800), B(153600), B(307200), B(614400)
#endif
};
#undef B

static
tcflag_t
map_n_to_bn(unsigned int n)
{
    size_t i;

    for (i = 0; i < sizeof(map)/sizeof(map[0]); i++) {
        if (map[i].n == n)
            return map[i].bn;
    }

    return B0;
}

static
unsigned int
map_bn_to_n(tcflag_t bn)
{
    size_t i;

    for (i = 0; i < sizeof(map)/sizeof(map[0]); i++) {
        if (map[i].bn == bn)
            return map[i].n;
    }

    return 0;
}


int
main(int argc, char *argv[])
{
    /* Declare tio structure, its type depends on supported ioctl */
#ifdef TCGETS2
    struct termios2 tio;
#else
    struct termios tio;
#endif
    unsigned int n;
    tcflag_t bn;
    int fd, rc;

    if (argc != 2 && argc != 3 && argc != 4) {
        fprintf(stderr, "Usage: %s device [output [input] ]\n", argv[0]);
        exit(EXIT_FAILURE);
    }

    fd = open(argv[1], O_RDWR | O_NONBLOCK | O_NOCTTY);
    if (fd < 0) {
        perror("open");
        exit(EXIT_FAILURE);
    }

    /* Get the current serial port settings via supported ioctl */
#ifdef TCGETS2
    rc = ioctl(fd, TCGETS2, &tio);
#else
    rc = ioctl(fd, TCGETS, &tio);
#endif
    if (rc) {
        perror("TCGETS");
        close(fd);
        exit(EXIT_FAILURE);
    }

    /* Change baud rate when more arguments were provided */
    if (argc == 3 || argc == 4) {
        /* Clear the current output baud rate and fill a new value */
        n = atoi(argv[2]);
        /* When possible prefer usage of Bnnn constant as glibc-based
           applications are not able to parse BOTHER c_ospeed baud rate */
        bn = map_n_to_bn(n);
        if (n != 0 && bn == B0) {
#ifdef BOTHER
            bn = BOTHER;
#else
            fprintf(stderr, "baud rate %u is unsupported\n", n);
            close(fd);
            exit(EXIT_FAILURE);
#endif
        }
        tio.c_cflag &= ~CBAUD;
        tio.c_cflag |= bn;
#ifdef BOTHER
        tio.c_ospeed = n;
#endif

        /* When 4th argument is not provided reuse output baud rate */
        if (argc == 4) {
            n = atoi(argv[3]);
            bn = map_n_to_bn(n);
            /* Clear the current input baud rate and fill a new value */
            if (n != 0 && bn == B0) {
#ifdef BOTHER
                bn = BOTHER;
#else
                fprintf(stderr, "baud rate %u is unsupported\n", n);
                close(fd);
                exit(EXIT_FAILURE);
#endif
            }
        }

        if ((tio.c_cflag & CBAUD) != bn) {
#ifdef IBSHIFT
            tio.c_cflag &= ~(CBAUD << IBSHIFT);
            tio.c_cflag |= bn << IBSHIFT;
#ifdef BOTHER
            tio.c_ispeed = n;
#endif
#else
            fprintf(stderr, "split baud rates are unsupported\n", n);
            close(fd);
            exit(EXIT_FAILURE);
#endif
        } else {
#ifdef IBSHIFT
            /* B0 sets the input baud to the output baud rate */
            tio.c_cflag &= ~(CBAUD << IBSHIFT);
            tio.c_cflag |= B0 << IBSHIFT;
#ifdef BOTHER
            tio.c_ispeed = 0;
#endif
#endif
        }

        /* Set new serial port settings via supported ioctl */
#ifdef TCSETS2
        rc = ioctl(fd, TCSETS2, &tio);
#else
        rc = ioctl(fd, TCSETS, &tio);
#endif
        if (rc) {
            perror("TCSETS");
            close(fd);
            exit(EXIT_FAILURE);
        }

        /* And get new values which were really configured */
#ifdef TCGETS2
        rc = ioctl(fd, TCGETS2, &tio);
#else
        rc = ioctl(fd, TCGETS, &tio);
#endif
        if (rc) {
            perror("TCGETS");
            close(fd);
            exit(EXIT_FAILURE);
        }
    }

    bn = tio.c_cflag & CBAUD;
#ifdef BOTHER
    if (bn == BOTHER)
        n = tio.c_ospeed;
    else
#endif
        n = map_bn_to_n(bn);
    printf("output baud rate: %u\n", n);

#ifdef IBSHIFT
    bn = (tio.c_cflag >> IBSHIFT) & CBAUD;
    if (bn == B0)
#endif
        bn = tio.c_cflag & CBAUD;
#ifdef BOTHER
    if (bn == BOTHER)
        n = tio.c_ispeed;
    else
#endif
        n = map_bn_to_n(bn);
    printf("input baud rate: %u\n", n);

    close(fd);
    exit(EXIT_SUCCESS);
}

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 19:50 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 19:50 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx308.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 464 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 8512 bytes --]

From: "Pali Rohár via Libc-alpha" <libc-alpha@sourceware.org>
To: linux-man@vger.kernel.org, Alejandro Colomar <alx.manpages@gmail.com>, Michael Kerrisk <mtk.manpages@gmail.com>
Cc: "Marek Behún" <kabel@kernel.org>, "G. Branden Robinson" <g.branden.robinson@gmail.com>, libc-alpha@sourceware.org
Subject: [PATCH v4] ioctl_tty.2: Add example how to get or set baudrate on the serial port
Date: Tue, 10 Aug 2021 21:49:28 +0200
Message-ID: <20210810194928.16408-1-pali@kernel.org>

Setting custom baudrate for which is not defined Bnnn constant is possible
via BOTHER flag and then filling speed in c_ospeed and c_ispeed fields.

These two fields are either in struct termios or struct termios2. Former
belongs to TCGETS/TCSETS ioctls, latter to TCGETS2/TCSETS2 ioctls.

BOTHER flag with these two fields and new struct termios2 is not supported
by older versions of include header files.

Some architectures (e.g. amd64) provide both struct termios and struct
termios2, but c_ospeed and c_ispeed are only in struct termios2.

Some other architectures (e.g. alpha) provide both struct termios and struct
termios2 and both have c_ospeed and c_ispeed fields.

And some other architectures (e.g. powerpc) provide only struct termios
(no struct termios2) and it has c_ospeed and c_ispeed fields.

So basically to support all architectures it is needed to use
struct termios2 when TCGETS2/TCSETS2 is supported. Otherwise it is needed
to use struct termios with TCGETS/TCSETS (case for e.g. powerpc).

Setting input baudrate is done via IBSHIFT macro.

Signed-off-by: Pali Rohár <pali@kernel.org>

---
Changes in v4:
* Add SPDX-License-Identifier
* Correctly process split baudrates (separate output and input) via IBSHIFT
* Update commit message

Changes in v3:
* Check support for custom baudrate only based on BOTHER macro
* Use TCGETS/TCSETS/termios when TCGETS2/TCSETS2/termios2 is not available

Changes in v2:
* Use \e for backslash
* Use exit(EXIT_*) instead of return num
* Sort includes
* Add comment about possible fallback
---
 man2/ioctl_tty.2 | 100 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 100 insertions(+)

diff --git a/man2/ioctl_tty.2 b/man2/ioctl_tty.2
index abfdc1e21fe9..7b2b03ff6757 100644
--- a/man2/ioctl_tty.2
+++ b/man2/ioctl_tty.2
@@ -796,6 +796,106 @@ main(void)
     close(fd);
 }
 .EE
+.PP
+Get or set arbitrary baudrate on the serial port.
+.PP
+.EX
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#include <asm/termbits.h>
+#include <fcntl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <sys/ioctl.h>
+#include <sys/types.h>
+#include <unistd.h>
+
+int
+main(int argc, char *argv[])
+{
+#ifndef BOTHER
+    fprintf(stderr, "BOTHER is unsupported\en");
+    /* Program may fallback to TCGETS/TCSETS with Bnnn constants */
+    exit(EXIT_FAILURE);
+#else
+    /* Declare tio structure, its type depends on supported ioctl */
+#ifdef TCGETS2
+    struct termios2 tio;
+#else
+    struct termios tio;
+#endif
+    int fd, rc;
+
+    if (argc != 2 && argc != 3 && argc != 4) {
+        fprintf(stderr, "Usage: %s device [output [input] ]\en", argv[0]);
+        exit(EXIT_FAILURE);
+    }
+
+    fd = open(argv[1], O_RDWR | O_NONBLOCK | O_NOCTTY);
+    if (fd < 0) {
+        perror("open");
+        exit(EXIT_FAILURE);
+    }
+
+    /* Get the current serial port settings via supported ioctl */
+#ifdef TCGETS2
+    rc = ioctl(fd, TCGETS2, &tio);
+#else
+    rc = ioctl(fd, TCGETS, &tio);
+#endif
+    if (rc) {
+        perror("TCGETS");
+        close(fd);
+        exit(EXIT_FAILURE);
+    }
+
+    /* Change baud rate when more arguments were provided */
+    if (argc == 3 || argc == 4) {
+        /* Clear the current output baud rate and fill a new value */
+        tio.c_cflag &= ~CBAUD;
+        tio.c_cflag |= BOTHER;
+        tio.c_ospeed = atoi(argv[2]);
+
+        /* Clear the current input baud rate and fill a new value */
+        tio.c_cflag &= ~(CBAUD << IBSHIFT);
+        tio.c_cflag |= BOTHER << IBSHIFT;
+        /* When 4th argument is not provided reuse output baud rate */
+        tio.c_ispeed = (argc == 4) ? atoi(argv[3]) : atoi(argv[2]);
+
+        /* Set new serial port settings via supported ioctl */
+#ifdef TCSETS2
+        rc = ioctl(fd, TCSETS2, &tio);
+#else
+        rc = ioctl(fd, TCSETS, &tio);
+#endif
+        if (rc) {
+            perror("TCSETS");
+            close(fd);
+            exit(EXIT_FAILURE);
+        }
+
+        /* And get new values which were really configured */
+#ifdef TCGETS2
+        rc = ioctl(fd, TCGETS2, &tio);
+#else
+        rc = ioctl(fd, TCGETS, &tio);
+#endif
+        if (rc) {
+            perror("TCGETS");
+            close(fd);
+            exit(EXIT_FAILURE);
+        }
+    }
+
+    close(fd);
+
+    printf("output baud rate: %u\en", tio.c_ospeed);
+    printf("input baud rate: %u\en", tio.c_ispeed);
+
+    exit(EXIT_SUCCESS);
+#endif
+}
+.EE
 .SH SEE ALSO
 .BR ldattach (1),
 .BR ioctl (2),
-- 
2.20.1



To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=df5a.6112d885.c270.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=%5BPATCH+v4%5D+ioctl_tty.2%3A+Add+example+how+to+get+or+set+baudrate+on+the+serial+port&verdict=C&c=bba6a45faa79c35a46e941bf6cdc12942e2af641

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 18:12 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 18:12 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx306.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 464 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Undelivered Message Headers --]
[-- Type: text/rfc822-headers, Size: 5019 bytes --]

Return-Path: <libc-alpha@sourceware.org>
Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) by
 fx306.security-mail.net (Postfix) with ESMTPS id EB0C4398F67 for
 <mpoulhies@kalray.eu>; Tue, 10 Aug 2021 20:12:19 +0200 (CEST)
Received: from server2.sourceware.org (localhost [IPv6:::1]) by
 sourceware.org (Postfix) with ESMTP id 31C34382D83F for
 <mpoulhies@kalray.eu>; Tue, 10 Aug 2021 18:12:19 +0000 (GMT)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com
 [IPv6:2607:f8b0:4864:20::102c]) by sourceware.org (Postfix) with ESMTPS id
 ED6A83969027 for <libc-alpha@sourceware.org>; Tue, 10 Aug 2021 18:05:45
 +0000 (GMT)
Received: by mail-pj1-x102c.google.com with SMTP id
 hv22-20020a17090ae416b0290178c579e424so305536pjb.3 for
 <libc-alpha@sourceware.org>; Tue, 10 Aug 2021 11:05:45 -0700 (PDT)
Received: from ?IPv6:2804:431:c7cb:9dce:5752:5b5a:453:cdda?
 ([2804:431:c7cb:9dce:5752:5b5a:453:cdda]) by smtp.gmail.com with ESMTPSA id
 c14sm28359788pgv.86.2021.08.10.11.05.42 (version=TLS1_3
 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Aug 2021 11:05:43 -0700
 (PDT)
X-Quarantine-ID: <NJzsM1Xei-Fu>
X-Virus-Scanned: E-securemail, by Secumail
X-Spam-Status: No, score=0.051 tagged_above=-1000 required=7.5
 tests=[AB_ENVFROM_LONG_40=0.5, AB_FAKE_WORD_1=0.2, AB_IN_REPLY_TO_EXISTS=-1,
 AB_LONG_SUBJ_30=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-1, DKIM_VALID_AU=-0.1,
 FSL_RCVD_EX_4=0.01, FSL_RCVD_UT_4=0.01, HEAD_NEWS=-0.5, MISSING_MID=0.14,
 MM_ENVFROM_BOUNCE=1, NICE_REPLY_A=1, RCVD_IN_DNSWL_MED=-1.3,
 S_FROM_GREY_MINUS_2=-2, S_KW_BODY_EXPLICIT_=2.5, S_KW_BODY__UPDATE_=0.5,
 T_RP_MATCHES_RCVD=-0.01] autolearn=disabled
Authentication-Results: fx306.security-mail.net (amavisd-new); dkim=pass
 (1024-bit key) header.d=sourceware.org
Secumail-id: <14e28.6112c183.e8ac1.0>
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 31C34382D83F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
 s=default; t=1628619139; bh=qsTHQwYvH6VTvgFk4Z4ICiGSrLFEc5UIEAqjK3AxWNc=;
 h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe:
 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From;
 b=LqB9Y/j0Z7Ll0rHNPodAjAe+ySOf0A77SXZ0ltgZIfyFedmYIbzg4IgzU5++psVoa
 NoQn04ip4I7VJqd1WTqBDo4EEcFF7b91QgEUTUULtJAPPGqUx1Rc/OGfYxudNAQue8
 iA+ZPRTsQBbfz0d1i30opDgSzaRT4SCpeNSOV1qU=
X-Original-To: libc-alpha@sourceware.org
Delivered-To: libc-alpha@sourceware.org
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ED6A83969027
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net;
 s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date
 :user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding; bh=qsTHQwYvH6VTvgFk4Z4ICiGSrLFEc5UIEAqjK3AxWNc=;
 b=Cg3m2P99dYJ3puDv6p+USGuN2lfLqaBRTtNw+Q4mBo6BIu0NfbRB7QicFpfqF6UlYa
 Tj31MpuM2ulNXT7cTrBolD/BFDbpHzBRaDqCDSoFaE4iKrZUTKyi6MjuvxVqj3k65zGu
 q511MOmIzmAUTYs8fHAa8v6H5LTauQ2Bu/5g1htWoYUNxJqrs9G8VfLt0CJTR963TLfP
 MacgL91xxZBtYvP1d5INdEDESM0c8r8tNuQsp7HdisnwFZ92fRtnMV1whj/iQNGMh/rv
 WXpzebHZJrW3Pyg5GCz4hQMb5rAcQpJ0lwkqxupRpTvVPzZeUUaWtXV67htEzZ6EWbto OQHw==
X-Gm-Message-State: AOAM531zNyOsQ1ZF7NwdevIYvViwPW3HY6KyJCNSH1Gu73BzGlKQfkiZ
 MruT1RnJko4vVb697NhOTNgfuA==
X-Google-Smtp-Source: ABdhPJzU8be/9/AVPT4He1/HrjWN3XU/jgsAePkSUhyA3+L7RXDYbrxjlw1I3XULTZvfBVY6AB9cWw==
X-Received: by 2002:a17:90a:2882:: with SMTP id
 f2mr33331332pjd.102.1628618744255;  Tue, 10 Aug 2021 11:05:44 -0700 (PDT)
Subject: Re: [PATCH v6 1/2] BZ #17645, fix slow DSO sorting behavior in
 dynamic loader -- Testing infrastructure
To: Chung-Lin Tang <cltang@codesourcery.com>, GNU C Library
 <libc-alpha@sourceware.org>, Florian Weimer <fweimer@redhat.com>
References: <bf24fd60-693c-4ac8-d84d-f1be69677351@codesourcery.com>
Message-ID: <9fa7d32b-ded3-f9e1-3dd1-acfa9c770c71@linaro.org>
Date: Tue, 10 Aug 2021 15:05:41 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <bf24fd60-693c-4ac8-d84d-f1be69677351@codesourcery.com>
Content-Language: en-us
X-BeenThere: libc-alpha@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=subscribe>
From: Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org>
Reply-To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Errors-To: libc-alpha-bounces+mpoulhies=kalray.eu@sourceware.org
Sender: Libc-alpha <libc-alpha-bounces+mpoulhies=kalray.eu@sourceware.org>
Content-Type: multipart/alternative; boundary="=_QH68mpBvgmUTxs-EJ4AnYCP"
X-ALTERMIMEV2_in: done

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 18:04 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 18:04 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx408.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 465 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 13280 bytes --]

From: "Binello, Severino via Libc-alpha" <libc-alpha@sourceware.org>
To: Ian Kent <ikent@redhat.com>, libc-alpha@sourceware.org, fweimer@redhat.com, "Marusic, Aljosa" <marusic@bnl.gov>
Subject: Re: Building sunrpc from glibc source
Date: Tue, 10 Aug 2021 17:47:18 +0000
Message-ID: <BLAPR09MB72335701AEE69D949908187BAAF79@BLAPR09MB7233.namprd09.prod.outlook.com>

Hello Ian and Florian

Thanks for the feedback, its much appreciated
Unfortunately Im not the best person to be asking the questions or providing the info
My role with our communication code right now is to get it to build

I am reaching out to the developer of our rpc based code to see if he can provide
a better picture and provide  further information.
So I am including Al Marusic in this email thread.

Thanks again!
-Sev

________________________________
From: Ian Kent <ikent@redhat.com>
Sent: Friday, August 6, 2021 8:27 PM
To: Binello, Severino <sev@bnl.gov>; libc-alpha@sourceware.org <libc-alpha@sourceware.org>
Subject: Re: Building sunrpc from glibc source


On 6/8/21 8:07 pm, Ian Kent wrote:
> On 6/8/21 7:12 am, Binello, Severino via Libc-alpha wrote:
>> Hello
>>
>>    As of RedHat 8, the sunrpc is no longer included with glibc shared
>> object library.
>> Unfortunately, our communications software would require extensive
>> redesign in order to use tirpc.
>
> For example?
>
> Can you describe the sort of challenges you have doing this please.
>
>
>> As such, we are looking into an alternative approach where we just
>> build the sunrpc portion from the glibc source tar file.
>> However, running into difficulties separating it out.
>> Can you recommend a method for just building the sunrpc code ?
>
> It's worth understanding what might be needed in order to use libtirpc
>
> first.
>
>
>>
>> Thanks Much
>> -Sev
>>
>> ps: Below is the reason why our code is incompatible with the tirpc
>> design
>> with old glibc every RPC server runs in its own thread,
>> with tirpc library there can be only one RPC server per program.
>> See:
>> from svc.c of tirpc library:
>>
>> static struct svc_callout /* removed declaration */ *svc_head;
>>
>> from svc.c of glibc-2.25:
>>
>> #ifdef _RPC_THREAD_SAFE_
>> #define svc_head RPC_THREAD_VARIABLE(svc_head_s)
>> #else
>> static struct svc_callout *svc_head;
>> #endif
>>
>> As you can see, if RPC_THREAD_SAFE_ is defined,
>> svc_head is per thread variable.
>
> I think I have some quick and nasty multi-thread libtirpc svc code
>
> kicking around somewhere (if I can find it now). It might be worth
>
> cleaning that up and maybe enhancing it a little, or maybe it's broken
>
> I don't know, but I'd recommend looking at that first, if there's not
>
> to many other problems to deal with.

Actually it looks like this was multi-threaded io not multi-threaded
servers.


But I'm not sure that you can't register multiple services in both glibc

and libtirpc, it's just that it's not thread safe to do so in glibc.


Maybe I don't understand what your doing, explain it please.


Why do you need a separate services list for each thread rather than a

library global lock protected services list as in libtirpc?


Ian



To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=13ff.6112bfbb.62774.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+Building+sunrpc+from+glibc+source&verdict=C&c=a117373547eef7f3412eefcf296fd8c3115d815f

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 18:03 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 18:03 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx601.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 464 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 13755 bytes --]

From: "Fāng-ruì Sòng via Libc-alpha" <libc-alpha@sourceware.org>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH v2 3/3] configure: Allow LD to be LLD 13.0.0 or above [BZ #26558]
Date: Tue, 10 Aug 2021 10:42:36 -0700
Message-ID: <CAFP8O3KmMzDJGw4VOjePLo+WNtt4HFpj12KHyC9xkSZTggRnJQ@mail.gmail.com>

On Tue, Aug 10, 2021 at 7:38 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Mon, Aug 9, 2021 at 12:59 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> >
> > On Mon, Aug 9, 2021 at 10:59 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > On Sat, Aug 7, 2021 at 9:17 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > > >
> > > >
> > > >
> > > > On 2021-08-07, H.J. Lu wrote:
> > > > >On Fri, Aug 6, 2021 at 5:48 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > > > >>
> > > > >> On 2021-08-05, H.J. Lu wrote:
> > > > >> >On Thu, Aug 5, 2021 at 9:43 AM Fāng-ruì Sòng <maskray@google.com> wrote:
> > > > >> >>
> > > > >> >> On Thu, Aug 5, 2021 at 9:34 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > >> >> >
> > > > >> >> > On Thu, Aug 5, 2021 at 9:29 AM Fangrui Song via Libc-alpha
> > > > >> >> > <libc-alpha@sourceware.org> wrote:
> > > > >> >> > >
> > > > >> >> > > When using LLD (LLVM linker) as the linker, configure prints a confusing
> > > > >> >> > > message.
> > > > >> >> > >
> > > > >> >> > >     *** These critical programs are missing or too old: GNU ld
> > > > >> >> > >
> > > > >> >> > > LLD>=13.0.0 can build glibc --enable-static-pie. (8.0.0 needs one
> > > > >> >> > > workaround for -Wl,-defsym=_begin=0. 9.0.0 works with
> > > > >> >> > > --disable-static-pie).
> > > > >> >> > >
> > > > >> >> > > With BZ #28153 (glibc bug exposed by testing with LLD) fixed,
> > > > >> >> > > `make check` only has 2 more failures with LLD than with GNU ld:
> > > > >> >> > > BZ #28154 (LLD follows the PowerPC port of GNU ld for ifunc by
> > > > >> >> > > placing IRELATIVE relocations in .rela.dyn).
> > > > >> >> >
> > > > >> >> > This is an lld bug, similar to:
> > > > >> >> >
> > > > >> >> > https://sourceware.org/bugzilla/show_bug.cgi?id=13302
> > > > >> >> >
> > > > >> >> > Please fix it at least on x86.
> > > > >> >>
> > > > >> >> I am afraid that I disagree. The PowerPC port of GNU ld does the right
> > > > >> >
> > > > >> >This is just one opinion and it doesn't make it "the right thing".
> > > > >> >
> > > > >> >> thing and LLD follows suit.
> > > > >> >> R_*_IRELATIVE relocations should be eagerly resolved, so they belong
> > > > >> >> to .rela.dyn instead of .rela.plt.
> > > > >> >
> > > > >> >Ulrich and I designed/implemented IFUNC on x86 and for x86.  I consider
> > > > >> >x86 implementation of IFUC as the gold standard.
> > > > >>
> > > > >> kib from FreeBSD said
> > > > >>
> > > > >> "FreeBSD rtld does the initial pass over the plt relocations and handles
> > > > >> R_X86_64_JMP_SLOT only, If there are any R_X86_64_IRELATIVE relocks, we
> > > > >> mark the object as having such relocations. Then, we do the ireloc
> > > > >> processing, using the depth-first descend. We handle all IRELOCs for
> > > > >> dependent objects before doing it for dependee. There, we iterate over
> > > > >> all plt relocs to select IRELOCs."
> > > > >>
> > > > >> I pondered at this comment
> > > > >>
> > > > >> /*
> > > > >>   * The handling of R_MACHINE_IRELATIVE relocations and jumpslots
> > > > >>   * referencing STT_GNU_IFUNC symbols is postponed till the other
> > > > >>   * relocations are done.  The indirect functions specified as
> > > > >>   * ifunc are allowed to call other symbols, so we need to have
> > > > >>   * objects relocated before asking for resolution from indirects.
> > > > >>   *
> > > > >>   * The R_MACHINE_IRELATIVE slots are resolved in greedy fashion,
> > > > >>   * instead of the usual lazy handling of PLT slots.  It is
> > > > >>   * consistent with how GNU does it.
> > > > >>   */
> > > > >>
> > > > >> and re-read https://sourceware.org/glibc/wiki/GNU_IFUNC
> > > > >>
> > > > >> "This may work on x86_64 where the R_*_IRELATIVE relocations happen in
> > > > >> DT_JMPREL after the DT_REL* relocations, but that is no guarantee that it will
> > > > >> work on AArch64, PPC64, or other architectures that are slightly different.
> > > > >> Such fundamental limitations may be lifted at a future point."
> > > > >>
> > > > >> I think adopting the FreeBSD approach can make IRELATIVE more robust, even for
> > > > >> x86. IRELATIVE is still eager resolved, just postponed after other relocations.
> > > > >> Fixing this property in glibc will improve rubustness/flexibility of ifunc
> > > > >> resolvers and freeing linkers the responsibility to order IRELATIVE in a
> > > > >> particular position.
> > > > >>
> > > > >> Pioneering on one feature gives the designer respect, yet the designer can only
> > > > >> earn authority by demonstrating the consideration of all sort of implication.
> > > > >>
> > > > >
> > > > >On Linux/x86, lld is incompatible with ld.so on this particular IFUNC feature.
> > > > >We have 3 choices:
> > > > >
> > > > >1. Ignore it.  But it means that if lld is used to build glibc, we don't know if
> > > > >this feature works or not.
> > > >
> > > > Let's ignore it :)
> > > >
> > > > It's just 2 tests, representing a corner case of IRELATIVE, which is
> > > > unreliable on non-x86 (as documented) and x86 (see below) anyway.
> > > >
> > > > >2. Change glibc to make it compatible with lld.
> > > > >3. Change lld to make it compatible with glibc.
> > > > >
> > > > >The FreeBSD scheme is not wrong.  But it is a workaround in glibc
> > > > >for a linker bug unless it also fixes other IFUNC issues on Linux/x86.
> > > >
> > > > Let me try convincing you that glibc should be fixed:)
> > > >
> > > >    // a.c
> > > >    #include <stdio.h>
> > > >
> > > >    int a_impl() { return 42; }
> > > >    void *a_resolver() {
> > > >      puts("a_resolver");
> > > >      return (void *)a_impl;
> > > >    }
> > > >    int a() __attribute__((ifunc("a_resolver")));
> > > >
> > > >    // .rela.dyn.rel => R_X86_64_64 referencing STT_GNU_IFUNC in .rela.dyn
> > > >    int (*fptr_a)() = a;
> > > >
> > > >    int main() { printf("%d\n", a()); }
> > > >
> > > > OK, let's compile with gcc and link with GNU ld:
> > > >
> > > > % cc -fpie -c a.c; cc -fuse-ld=bfd -pie a.o -o a; ./a
> > > > [1]    170657 segmentation fault  ./a
> > > >
> > > > Oops. The segfault is very similar to the 2 ld.lld FAIL.
> > >
> > > There are restrictions on how IFUNC can be used.   If we want to
> > > support this use case, we need to change ld.so or/and linker.
> >
> > Since you are familiar with dynamic linking, perhaps you can offer the
> > ld.so fix  (postponing ifunc resolver invocation after other regular
> > relocations) :)
>
> Please open a glibc bug so that we can track it.   We should first
> decide if we want to support this use case.

https://sourceware.org/bugzilla/show_bug.cgi?id=28218
("ld.so: ifunc resolver calls a lazy PLT. When does it work?")

> > Once a separate relocation loop for ifunc is created, it is trivial
> > for non-x86 arch maintainers to make ifunc more reliable for their
> > arches.
> >
> > Then users can build more trust on ifunc.
> >
> >
> > Let me consider this sub-thread a non-blocker for LLD 13.0.0 support.
> >
> > > > Now, you may say, we can change GNU ld to emit R_X86_64_IRELATIVE instead of R_X86_64_64.
> > > >
> > > > Then let's try this:
> > > >
> > > >    // b.c
> > > >    #include <stdio.h>
> > > >
> > > >    int b_impl() { return 42; }
> > > >    void *b_resolver() {
> > > >      puts("b resolver");
> > > >      return (void *)b_impl;
> > > >    }
> > > >    int b() __attribute__((ifunc("b_resolver")));
> > > >
> > > >    int (*fptr_b)() = b;
> > > >
> > > > cc b.c -fpic -shared -o b.so
> > > > Make it a DT_NEEDED of a and see the crash again. b is preemptible so IRELATIVE is not correct.
> > >
> > > I don't believe this is the use case we want to support.
> >
> > Do we have easy-to-explain words on what's supported and what's not?
>
> This has been a recurring topic. We should have some guidance
> on IFUNC.  IFUNC was designed for glibc.  It was later extended to
> other use cases.  There are limitations, like
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=20019
>
> We need clear descriptions about how IFUNC should be used.
>
> > > >
> > > > If glibc adopts the FreeBSD model, then all these will be good, along with LLD's .rela.dyn IRELATIVE.
> > > > An ifunc resolver can call functions defined in an arbitrary DT_NEEDED.
> > >
> > >
> > >
> > > --
> > > H.J.
>
>
>
> --
> H.J.


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=153.6112bf75.cd1b8.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+%5BPATCH+v2+3%2F3%5D+configure%3A+Allow+LD+to+be+LLD+13.0.0+or+above+%5BBZ+%2326558%5D&verdict=C&c=b66724c82cc7908c8c60246cb32098d762ef4505

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 17:48 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 17:48 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx405.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 464 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Undelivered Message Headers --]
[-- Type: text/rfc822-headers, Size: 5308 bytes --]

Return-Path: <libc-alpha@sourceware.org>
Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) by
 fx405.security-mail.net (Postfix) with ESMTPS id 45A343237EF for
 <mpoulhies@kalray.eu>; Tue, 10 Aug 2021 19:47:10 +0200 (CEST)
Received: from server2.sourceware.org (localhost [IPv6:::1]) by
 sourceware.org (Postfix) with ESMTP id 788DA385741F for
 <mpoulhies@kalray.eu>; Tue, 10 Aug 2021 17:47:05 +0000 (GMT)
Received: from butterfly.birch.relay.mailchannels.net
 (butterfly.birch.relay.mailchannels.net [23.83.209.27]) by sourceware.org
 (Postfix) with ESMTPS id 734A13958C14 for <libc-alpha@sourceware.org>; Tue,
 10 Aug 2021 17:39:58 +0000 (GMT)
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by
 relay.mailchannels.net (Postfix) with ESMTP id 611166422FB; Tue, 10 Aug 2021
 17:39:54 +0000 (UTC)
Received: from pdx1-sub0-mail-a89.g.dreamhost.com
 (100-96-16-111.trex.outbound.svc.cluster.local [100.96.16.111])
 (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with
 ESMTPA id B282C642859; Tue, 10 Aug 2021 17:39:52 +0000 (UTC)
Received: from pdx1-sub0-mail-a89.g.dreamhost.com (pop.dreamhost.com
 [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by
 100.96.16.111 (trex/6.3.3); Tue, 10 Aug 2021 17:39:54 +0000
Received: from pdx1-sub0-mail-a89.g.dreamhost.com (localhost [127.0.0.1]) by
 pdx1-sub0-mail-a89.g.dreamhost.com (Postfix) with ESMTP id E95A184D89; Tue,
 10 Aug 2021 10:39:47 -0700 (PDT)
Received: from rhbox.redhat.com (unknown [1.186.101.110]) (using TLSv1.2
 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client
 certificate requested) (Authenticated sender: siddhesh@gotplt.org) by
 pdx1-sub0-mail-a89.g.dreamhost.com (Postfix) with ESMTPSA id B157D83F04;
 Tue, 10 Aug 2021 10:39:17 -0700 (PDT)
X-Quarantine-ID: <dwWq5Xf0I6T7>
X-Virus-Scanned: E-securemail, by Secumail
X-Spam-Status: Yes, score=21.371 tagged_above=-1000 required=7.5
 tests=[AB_ENVFROM_LONG_40=0.5, AB_FAKE_WORD_1=0.2, AB_IN_REPLY_TO_EXISTS=-1,
 AB_LONG_SUBJ_30=0.001, AB_URI_URL_VLIKELY_SPAMMER_3=2, DKIM_SIGNED=0.1,
 DKIM_VALID=-1, DKIM_VALID_AU=-0.1, FSL_RCVD_EX_GT_5=1,
 FSL_RCVD_UT_GT_5=0.01, HEAD_NEWS=-0.5, HK_MUCHMONEY=0.001, MISSING_MID=0.14,
 MM_ENVFROM_BOUNCE=1, RCVD_IN_DNSWL_MED=-1.3, RCVD_IN_UCE_3=0.001,
 RCVD_IN_UCE_LE_3=0.005, RDNS_DYNAMIC=0.363, S_FROM_GREY_MINUS_2=-2,
 S_KW_BODY_BALLY=0.45, S_KW_BODY_CUNI=2.5, S_KW_BODY_DEBT=2.5,
 S_KW_BODY_DICK=2.5, S_KW_BODY_EXPLICIT_=2.5, S_META_SUM_GT_EOM=1.499,
 S_META_SUM_GT_FAKE_INSURANCE=2.495, S_META_SUM_GT_SELL_DIPLOMAS=3.998,
 S_META_SUM_GT_SEX_AND_MULTIMEDIA=2.498, T_CN_URL=0.01, T_FRT_CONTACT=0.01,
 T_RP_MATCHES_RCVD=-0.01, UPPERCASE_URI=1] autolearn=disabled
Authentication-Results: fx405.security-mail.net (amavisd-new); dkim=pass
 (1024-bit key) header.d=sourceware.org
Secumail-id: <10560.6112bb9e.42263.0>
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 788DA385741F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
 s=default; t=1628617627; bh=enqBjIfV6/zg7sG7M1nEPQRTulkzbQt8nmll0gzRR7A=;
 h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe:
 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From;
 b=gtCsPRgz+0jL1IbBwcDA5T1B+Y6fDE9pdCDt23uYMzgH1O01gGeqGDPv9tL7dvFvk
 KUD896s+Pl0B47bWKsIXYDFj9vRIm5PJH+Rh0Wxb3k90Tsjq4Uz0A0AON3RzLqCPcQ
 5zRCFtTCdiqRFS1ETrYMmqqWl25TKm25pvQCbA+Y=
X-Original-To: libc-alpha@sourceware.org
Delivered-To: libc-alpha@sourceware.org
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 734A13958C14
X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org, dreamhost|x-authsender|siddhesh@gotplt.org
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org
X-MailChannels-Auth-Id: dreamhost
X-Thread-Zesty: 733436324d8a15ea_1628617194189_1984571110
X-MC-Loop-Signature: 1628617194189:1184195423
X-MC-Ingress-Time: 1628617194188
X-DH-BACKEND: pdx1-sub0-mail-a89
To: libc-alpha@sourceware.org
Subject: [SPAM] [PATCH v3 2/2] Remove "Contributed by" lines
Date: Tue, 10 Aug 2021 23:08:54 +0530
Message-ID: <20210810173854.1326070-3-siddhesh@sourceware.org>
X-Mailer: git-send-email 2.31.1
In-Reply-To: <20210810173854.1326070-1-siddhesh@sourceware.org>
References: <20210810173854.1326070-1-siddhesh@sourceware.org>
MIME-Version: 1.0
X-BeenThere: libc-alpha@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=subscribe>
From: Siddhesh Poyarekar via Libc-alpha <libc-alpha@sourceware.org>
Reply-To: Siddhesh Poyarekar <siddhesh@sourceware.org>
Cc: joseph@codesourcery.com
Errors-To: libc-alpha-bounces+mpoulhies=kalray.eu@sourceware.org
Sender: Libc-alpha <libc-alpha-bounces+mpoulhies=kalray.eu@sourceware.org>
Content-Type: multipart/alternative; boundary="=_fxNiJV1JWGXwqaFWNv0Lzcf"
X-ALTERMIMEV2_in: done
Content-Transfer-Encoding: 8bit

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 17:41 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 17:41 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx304.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 463 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 14626 bytes --]

From: Siddhesh Poyarekar via Libc-alpha <libc-alpha@sourceware.org>
To: libc-alpha@sourceware.org
Cc: joseph@codesourcery.com
Subject: [PATCH v3 1/2] Port shared code information from the wiki
Date: Tue, 10 Aug 2021 23:08:53 +0530
Message-ID: <20210810173854.1326070-2-siddhesh@sourceware.org>

Since the shared code now has special status with respect to
copyrights, port them into a more structured format in the source tree
and add a python function that parses and returns a dictionary with
the information.

I need this to exclude these files from the Contributed-by changes and
I reckon it would be useful to know these files for future tooling.
---
 SHARED-FILES                 | 206 +++++++++++++++++++++++++++++++++++
 scripts/glibc_shared_code.py |  70 ++++++++++++
 2 files changed, 276 insertions(+)
 create mode 100644 SHARED-FILES
 create mode 100644 scripts/glibc_shared_code.py

diff --git a/SHARED-FILES b/SHARED-FILES
new file mode 100644
index 0000000000..d1c4fc4eeb
--- /dev/null
+++ b/SHARED-FILES
@@ -0,0 +1,206 @@
+# Files shared with other projects.  Pass a file path to the
+# get_glibc_shared_code() function in the python library
+# scripts/glibc_shared_code.py to get a dict object with this information.  See
+# the library sources for more information.
+
+# The headers on most of these files indicate that glibc is the canonical
+# source for these files, although in many cases there seem to be useful
+# changes in the gnulib versions that could be merged back in. Not all gnulib
+# files contain such a header and it is not always consistent in its format, so
+# it would be useful to make sure that all gnulib files that are using glibc as
+# upstream have a greppable header.
+#
+# These files are quite hard to find without a header to grep for and each file
+# has to be compared manually so this list is likely incomplete or may contain
+# errors.
+gnulib:
+  argp/argp-ba.c
+  argp/argp-ba.c
+  argp/argp-eexst.c
+  argp/argp-fmtstream.c
+  argp/argp-fmtstream.h
+  argp/argp-fs-xinl.c
+  argp/argp-help.c
+  argp/argp-namefrob.h
+  argp/argp-parse.c
+  argp/argp-pv.c
+  argp/argp-pvh.c
+  argp/argp-xinl.c
+  argp/argp.h
+  crypt/md5.c
+  crypt/md5.h
+  dirent/alphasort.c
+  dirent/scandir.c
+  locale/programs/3level.h
+  # Merged from gnulib 2014-6-23
+  malloc/obstack.c
+  # Merged from gnulib 2014-6-23
+  malloc/obstack.h
+  # Merged from gnulib 2014-07-10
+  misc/error.c
+  misc/error.h
+  misc/getpass.c
+  misc/mkdtemp.c
+  posix/fnmatch_loop.c
+  # Intended to be the same. Gnulib copy contains glibc changes.
+  posix/getopt.c
+  # Intended to be the same. Gnulib copy contains glibc changes.
+  posix/getopt1.c
+  # Intended to be the same. Gnulib copy contains glibc changes.
+  posix/getopt_int.h
+  posix/glob.c
+  posix/regcomp.c
+  posix/regex.c
+  posix/regex.h
+  posix/regex_internal.c
+  posix/regex_internal.h
+  posix/regexec.c
+  posix/spawn.c
+  posix/spawn_faction_addclose.c
+  posix/spawn_faction_adddup2.c
+  posix/spawn_faction_addopen.c
+  posix/spawn_faction_destroy.c
+  posix/spawn_faction_init.c
+  posix/spawn_int.h
+  posix/spawnattr_destroy.c
+  posix/spawnattr_getdefault.c
+  posix/spawnattr_getflags.c
+  posix/spawnattr_getpgroup.c
+  posix/spawnattr_getschedparam.c
+  posix/spawnattr_getschedpolicy.c
+  posix/spawnattr_getsigmask.c
+  posix/spawnattr_init.c
+  posix/spawnattr_setdefault.c
+  posix/spawnattr_setflags.c
+  posix/spawnattr_setpgroup.c
+  posix/spawnattr_setschedparam.c
+  posix/spawnattr_setschedpolicy.c
+  posix/spawnattr_setsigmask.c
+  posix/spawnp.c
+  stdlib/atoll.c
+  stdlib/getsubopt.c
+  stdlib/setenv.c
+  stdlib/strtoll.c
+  stdlib/strtoul.c
+  # Merged from gnulib 2014-6-26, needs merge back
+  string/memchr.c
+  string/memcmp.c
+  string/memmem.c
+  string/mempcpy.c
+  string/memrchr.c
+  string/rawmemchr.c
+  string/stpcpy.c
+  string/stpncpy.c
+  string/str-two-way.h
+  string/strcasestr.c
+  string/strcspn.c
+  string/strdup.c
+  string/strndup.c
+  string/strpbrk.c
+  string/strsignal.c
+  string/strstr.c
+  string/strtok_r.c
+  string/strverscmp.c
+  sysdeps/generic/pty-private.h
+  sysdeps/generic/siglist.h
+  sysdeps/posix/euidaccess.c
+  sysdeps/posix/gai_strerror.c
+  sysdeps/posix/getcwd.c
+  sysdeps/posix/pwrite.c
+  sysdeps/posix/spawni.c
+  # Merged from gnulib 2014-6-23
+  sysdeps/posix/tempname.c
+  # Merged from gnulib 2014-6-27
+  time/mktime.c
+  time/strptime.c
+  time/timegm.c
+
+# The last merge was 2014-12-11 and merged gettext 0.19.3 into glibc with a
+# patch submitted to the gettext mailing list for changes that could be merged
+# back.
+#
+# This commit was omitted from the merge as it does not appear to be compatible
+# with how glibc expects things to work:
+#
+# commit 279b57fc367251666f00e8e2b599b83703451afb
+# Author: Bruno Haible <bruno@clisp.org>
+# Date:   Fri Jun 14 12:03:49 2002 +0000
+#
+#     Make absolute pathnames inside $LANGUAGE work.
+gettext:
+  intl/bindtextdom.c
+  intl/dcgettext.c
+  intl/dcigettext.c
+  intl/dcngettext.c
+  intl/dgettext.c
+  intl/dngettext.c
+  intl/explodename.c
+  intl/finddomain.c
+  intl/gettext.c
+  intl/gettextP.h
+  intl/gmo.h
+  intl/hash-string.c
+  intl/hash-string.h
+  intl/l10nflist.c
+  intl/loadinfo.h
+  intl/loadmsgcat.c
+  intl/locale.alias
+  intl/localealias.c
+  intl/ngettext.c
+  intl/plural-exp.c
+  intl/plural-exp.h
+  intl/plural.y
+  intl/textdomain.c
+
+# The following files are shared with the upstream Unicode project and must be
+# updated regularly to stay in sync with the upstream unicode releases.
+#
+# Merged from Unicode 13.0.0 release.
+unicode:
+  localedata/unicode-gen/UnicodeData.txt
+  localedata/unicode-gen/unicode-license.txt
+  localedata/unicode-gen/DerivedCoreProperties.txt
+  localedata/unicode-gen/EastAsianWidth.txt
+  localedata/unicode-gen/PropList.txt
+
+# The following files are shared with the upstream tzcode project and must be
+# updated regularly to stay in sync with the upstream releases.
+#
+# Update from tzcode 2017b.
+# Latest is 2018g:
+#   https://mm.icann.org/pipermail/tz-announce/2018-October/000052.html
+tzcode:
+  timezone/private.h
+  timezone/tzfile.h
+  timezone/zdump.c
+  timezone/zic.c
+  timezone/tzselect.ksh
+
+# The following files are shared with the upstream tzdata project but is not
+# synchronized regularly. The data files themselves are used only for testing
+# purposes and their data is never used to generate any output. We synchronize
+# them only to stay on top of newer data that might help with testing.
+#
+# Currently synced to 2009i.  Latest is 2018g.
+# https://mm.icann.org/pipermail/tz-announce/2018-October/000052.html
+tzdata:
+  timezone/africa
+  timezone/antarctica
+  timezone/asia
+  timezone/australasia
+  timezone/europe
+  timezone/northamerica
+  timezone/southamerica
+  timezone/pacificnew
+  timezone/etcetera
+  timezone/factory
+  timezone/backward
+  timezone/systemv
+  timezone/solar87
+  timezone/solar88
+  timezone/solar89
+  timezone/iso3166.tab
+  timezone/zone.tab
+  timezone/leapseconds
+  # This is yearistype.sh in the parent project
+  timezone/yearistype
diff --git a/scripts/glibc_shared_code.py b/scripts/glibc_shared_code.py
new file mode 100644
index 0000000000..873a26117f
--- /dev/null
+++ b/scripts/glibc_shared_code.py
@@ -0,0 +1,70 @@
+#!/usr/bin/python
+# Copyright (C) 2021 Free Software Foundation, Inc.
+# This file is part of the GNU C Library.
+#
+# The GNU C Library is free software; you can redistribute it and/or
+# modify it under the terms of the GNU Lesser General Public
+# License as published by the Free Software Foundation; either
+# version 2.1 of the License, or (at your option) any later version.
+#
+# The GNU C Library is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# Lesser General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public
+# License along with the GNU C Library; if not, see
+# <https://www.gnu.org/licenses/>.
+
+def get_glibc_shared_code(path):
+    """ Get glibc shared code information from a file
+
+    The input file must have project names in their own line ending with a colon
+    and all shared files in the project on their own lines following the project
+    name.  Whitespaces are ignored.  Lines with # as the first non-whitespace
+    character are ignored.
+
+    Args:
+        path: The path to file containing shared code information.
+
+    Returns:
+        A dictionary with project names as key and lists of files as values.
+    """
+
+    projects = {}
+    with open(path, 'r') as f:
+        for line in f.readlines():
+            line = line.strip()
+            if len(line) == 0 or line[0] == '#':
+                continue
+            if line[-1] == ':':
+                cur = line[:-1]
+                projects[cur] = []
+            else:
+                projects[cur].append(line)
+
+    return projects
+
+# Function testing.
+import sys
+from os import EX_NOINPUT
+from os.path import exists
+from pprint import *
+
+if __name__ == '__main__':
+    if len(sys.argv) != 2:
+        print('Usage: %s <file name>' % sys.argv[0])
+        print('Run this script from the base glibc source directory')
+        sys.exit(EX_NOINPUT)
+
+    print('Testing get_glibc_shared_code with %s:\n' % sys.argv[1])
+    r = get_glibc_shared_code(sys.argv[1])
+    errors = False
+    for k in r.keys():
+        for f in r[k]:
+            if not exists(f):
+                print('%s does not exist' % f)
+                errors = True
+
+    if not errors:
+        pprint(r)
-- 
2.31.1



To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=1155.6112ba28.e25d0.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=%5BPATCH+v3+1%2F2%5D+Port+shared+code+information+from+the+wiki&verdict=C&c=cb9301e6249ad7e88b90b6078fd601c80d071fea

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 17:39 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 17:39 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx408.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 465 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Undelivered Message Headers --]
[-- Type: text/rfc822-headers, Size: 4800 bytes --]

Return-Path: <libc-alpha@sourceware.org>
Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) by
 fx408.security-mail.net (Postfix) with ESMTPS id 2D66C1B7B1BB for
 <mpoulhies@kalray.eu>; Tue, 10 Aug 2021 19:39:47 +0200 (CEST)
Received: from server2.sourceware.org (localhost [IPv6:::1]) by
 sourceware.org (Postfix) with ESMTP id 0498C384002E for
 <mpoulhies@kalray.eu>; Tue, 10 Aug 2021 17:39:45 +0000 (GMT)
Received: from cyan.elm.relay.mailchannels.net
 (cyan.elm.relay.mailchannels.net [23.83.212.47]) by sourceware.org (Postfix)
 with ESMTPS id 9117D385841D for <libc-alpha@sourceware.org>; Tue, 10 Aug
 2021 17:39:15 +0000 (GMT)
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by
 relay.mailchannels.net (Postfix) with ESMTP id B0513701EEC; Tue, 10 Aug 2021
 17:39:13 +0000 (UTC)
Received: from pdx1-sub0-mail-a89.g.dreamhost.com
 (100-96-16-111.trex-nlb.outbound.svc.cluster.local [100.96.16.111])
 (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with
 ESMTPA id CCDF0701F9C; Tue, 10 Aug 2021 17:39:12 +0000 (UTC)
Received: from pdx1-sub0-mail-a89.g.dreamhost.com (pop.dreamhost.com
 [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by
 100.96.16.111 (trex/6.3.3); Tue, 10 Aug 2021 17:39:13 +0000
Received: from pdx1-sub0-mail-a89.g.dreamhost.com (localhost [127.0.0.1]) by
 pdx1-sub0-mail-a89.g.dreamhost.com (Postfix) with ESMTP id 7A15D84D89; Tue,
 10 Aug 2021 10:39:12 -0700 (PDT)
Received: from rhbox.redhat.com (unknown [1.186.101.110]) (using TLSv1.2
 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client
 certificate requested) (Authenticated sender: siddhesh@gotplt.org) by
 pdx1-sub0-mail-a89.g.dreamhost.com (Postfix) with ESMTPSA id BD47E7EFDF;
 Tue, 10 Aug 2021 10:39:05 -0700 (PDT)
X-Quarantine-ID: <VH7CcQgaGKpr>
X-Virus-Scanned: E-securemail, by Secumail
X-Spam-Status: No, score=5.393 tagged_above=-1000 required=7.5
 tests=[AB_ENVFROM_LONG_40=0.5, AB_FAKE_WORD_1=0.2, AB_LONG_SUBJ_30=0.001,
 BL_ENHANCE_16=1.6, DKIM_SIGNED=0.1, DKIM_VALID=-1, DKIM_VALID_AU=-0.1,
 FD_GREY_OFFSET_2=2, FSL_RCVD_EX_GT_5=1, FSL_RCVD_UT_GT_5=0.01,
 HEAD_NEWS=-0.5, MISSING_MID=0.14, MM_ENVFROM_BOUNCE=1,
 RCVD_IN_BL_SPAMCOP_NET=1.246, RCVD_IN_DNSWL_MED=-1.3, RCVD_IN_UCE_3=0.001,
 RCVD_IN_UCE_LE_3=0.005, S_FROM_GREY_MINUS_2=-2, S_KW_BODY_EXPLICIT_=2.5,
 T_RP_MATCHES_RCVD=-0.01] autolearn=disabled
Authentication-Results: fx408.security-mail.net (amavisd-new); dkim=pass
 (1024-bit key) header.d=sourceware.org
Secumail-id: <118d.6112b9e3.1c191.0>
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0498C384002E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
 s=default; t=1628617185; bh=NIJ69ljYgUnaXbL5usOqQR8WAZmU5PMFsaX5rNSirag=;
 h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post:
 List-Help:List-Subscribe:From:Reply-To:Cc:From;
 b=XWKapAQjjgSQKwm6Z1aG58SpG9Vz54O0GytRVi+F5g4dZ6WMoAg98Xp++tDpDTImZ
 tt+kkQ6XNI3gtbnZ7Ic9N9AScKAkvYFPAS6O6+N9Tc29BnR0jVeIb/iKT5Gwt5RekB
 VSS/EhwaftjQpjlOVxAa91R/RZF/kXnzNwpAA+rU=
X-Original-To: libc-alpha@sourceware.org
Delivered-To: libc-alpha@sourceware.org
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9117D385841D
X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org, dreamhost|x-authsender|siddhesh@gotplt.org
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org
X-MailChannels-Auth-Id: dreamhost
X-Sponge-Arithmetic: 6671d2ee54fa3cf6_1628617153186_4210423336
X-MC-Loop-Signature: 1628617153186:1658125025
X-MC-Ingress-Time: 1628617153185
X-DH-BACKEND: pdx1-sub0-mail-a89
To: libc-alpha@sourceware.org
Subject: [PATCH v3 0/2] Source attribution cleanups
Date: Tue, 10 Aug 2021 23:08:52 +0530
Message-ID: <20210810173854.1326070-1-siddhesh@sourceware.org>
X-Mailer: git-send-email 2.31.1
MIME-Version: 1.0
X-BeenThere: libc-alpha@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=subscribe>
From: Siddhesh Poyarekar via Libc-alpha <libc-alpha@sourceware.org>
Reply-To: Siddhesh Poyarekar <siddhesh@sourceware.org>
Cc: joseph@codesourcery.com
Errors-To: libc-alpha-bounces+mpoulhies=kalray.eu@sourceware.org
Sender: Libc-alpha <libc-alpha-bounces+mpoulhies=kalray.eu@sourceware.org>
Content-Type: multipart/alternative; boundary="=_Awcape8dq37u326jzeDGyQo"
X-ALTERMIMEV2_in: done

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 15:42 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 15:42 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx304.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 463 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 5826 bytes --]

From: Siddhesh Poyarekar via Libc-alpha <libc-alpha@sourceware.org>
To: Joseph Myers <joseph@codesourcery.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH] Remove "Contributed by" lines
Date: Tue, 10 Aug 2021 21:12:21 +0530
Message-ID: <b8b85e47-55c2-26ec-e192-a3e19b273dc6@sourceware.org>

On 8/10/21 9:01 PM, Joseph Myers wrote:
> This file comes verbatim from tzcode (see timezone/README); we shouldn't
> modify it locally (including any "Contributed by" removal).
> 

Carlos pointed that out to me offline.  I'm working on a more elaborate 
change that avoids modifying all shared source code for now.  I'll post 
a v3 soon.

Thanks,
Siddhesh


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=884f.61129e7b.4d8d.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+%5BPATCH%5D+Remove+%22Contributed+by%22+lines&verdict=C&c=7ee0112cfa574051d92db6c7167fff7a226efe4d

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 14:39 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 14:39 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx302.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 465 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 13130 bytes --]

From: "H.J. Lu via Libc-alpha" <libc-alpha@sourceware.org>
To: "Fāng-ruì Sòng" <maskray@google.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH v2 3/3] configure: Allow LD to be LLD 13.0.0 or above [BZ #26558]
Date: Tue, 10 Aug 2021 07:38:02 -0700
Message-ID: <CAMe9rOotDYE2=JNg1MBMKgGQCgXWdd33tk6xgAc8UJqpu3nr-w@mail.gmail.com>

On Mon, Aug 9, 2021 at 12:59 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>
> On Mon, Aug 9, 2021 at 10:59 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Sat, Aug 7, 2021 at 9:17 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > >
> > >
> > >
> > > On 2021-08-07, H.J. Lu wrote:
> > > >On Fri, Aug 6, 2021 at 5:48 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > > >>
> > > >> On 2021-08-05, H.J. Lu wrote:
> > > >> >On Thu, Aug 5, 2021 at 9:43 AM Fāng-ruì Sòng <maskray@google.com> wrote:
> > > >> >>
> > > >> >> On Thu, Aug 5, 2021 at 9:34 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > >> >> >
> > > >> >> > On Thu, Aug 5, 2021 at 9:29 AM Fangrui Song via Libc-alpha
> > > >> >> > <libc-alpha@sourceware.org> wrote:
> > > >> >> > >
> > > >> >> > > When using LLD (LLVM linker) as the linker, configure prints a confusing
> > > >> >> > > message.
> > > >> >> > >
> > > >> >> > >     *** These critical programs are missing or too old: GNU ld
> > > >> >> > >
> > > >> >> > > LLD>=13.0.0 can build glibc --enable-static-pie. (8.0.0 needs one
> > > >> >> > > workaround for -Wl,-defsym=_begin=0. 9.0.0 works with
> > > >> >> > > --disable-static-pie).
> > > >> >> > >
> > > >> >> > > With BZ #28153 (glibc bug exposed by testing with LLD) fixed,
> > > >> >> > > `make check` only has 2 more failures with LLD than with GNU ld:
> > > >> >> > > BZ #28154 (LLD follows the PowerPC port of GNU ld for ifunc by
> > > >> >> > > placing IRELATIVE relocations in .rela.dyn).
> > > >> >> >
> > > >> >> > This is an lld bug, similar to:
> > > >> >> >
> > > >> >> > https://sourceware.org/bugzilla/show_bug.cgi?id=13302
> > > >> >> >
> > > >> >> > Please fix it at least on x86.
> > > >> >>
> > > >> >> I am afraid that I disagree. The PowerPC port of GNU ld does the right
> > > >> >
> > > >> >This is just one opinion and it doesn't make it "the right thing".
> > > >> >
> > > >> >> thing and LLD follows suit.
> > > >> >> R_*_IRELATIVE relocations should be eagerly resolved, so they belong
> > > >> >> to .rela.dyn instead of .rela.plt.
> > > >> >
> > > >> >Ulrich and I designed/implemented IFUNC on x86 and for x86.  I consider
> > > >> >x86 implementation of IFUC as the gold standard.
> > > >>
> > > >> kib from FreeBSD said
> > > >>
> > > >> "FreeBSD rtld does the initial pass over the plt relocations and handles
> > > >> R_X86_64_JMP_SLOT only, If there are any R_X86_64_IRELATIVE relocks, we
> > > >> mark the object as having such relocations. Then, we do the ireloc
> > > >> processing, using the depth-first descend. We handle all IRELOCs for
> > > >> dependent objects before doing it for dependee. There, we iterate over
> > > >> all plt relocs to select IRELOCs."
> > > >>
> > > >> I pondered at this comment
> > > >>
> > > >> /*
> > > >>   * The handling of R_MACHINE_IRELATIVE relocations and jumpslots
> > > >>   * referencing STT_GNU_IFUNC symbols is postponed till the other
> > > >>   * relocations are done.  The indirect functions specified as
> > > >>   * ifunc are allowed to call other symbols, so we need to have
> > > >>   * objects relocated before asking for resolution from indirects.
> > > >>   *
> > > >>   * The R_MACHINE_IRELATIVE slots are resolved in greedy fashion,
> > > >>   * instead of the usual lazy handling of PLT slots.  It is
> > > >>   * consistent with how GNU does it.
> > > >>   */
> > > >>
> > > >> and re-read https://sourceware.org/glibc/wiki/GNU_IFUNC
> > > >>
> > > >> "This may work on x86_64 where the R_*_IRELATIVE relocations happen in
> > > >> DT_JMPREL after the DT_REL* relocations, but that is no guarantee that it will
> > > >> work on AArch64, PPC64, or other architectures that are slightly different.
> > > >> Such fundamental limitations may be lifted at a future point."
> > > >>
> > > >> I think adopting the FreeBSD approach can make IRELATIVE more robust, even for
> > > >> x86. IRELATIVE is still eager resolved, just postponed after other relocations.
> > > >> Fixing this property in glibc will improve rubustness/flexibility of ifunc
> > > >> resolvers and freeing linkers the responsibility to order IRELATIVE in a
> > > >> particular position.
> > > >>
> > > >> Pioneering on one feature gives the designer respect, yet the designer can only
> > > >> earn authority by demonstrating the consideration of all sort of implication.
> > > >>
> > > >
> > > >On Linux/x86, lld is incompatible with ld.so on this particular IFUNC feature.
> > > >We have 3 choices:
> > > >
> > > >1. Ignore it.  But it means that if lld is used to build glibc, we don't know if
> > > >this feature works or not.
> > >
> > > Let's ignore it :)
> > >
> > > It's just 2 tests, representing a corner case of IRELATIVE, which is
> > > unreliable on non-x86 (as documented) and x86 (see below) anyway.
> > >
> > > >2. Change glibc to make it compatible with lld.
> > > >3. Change lld to make it compatible with glibc.
> > > >
> > > >The FreeBSD scheme is not wrong.  But it is a workaround in glibc
> > > >for a linker bug unless it also fixes other IFUNC issues on Linux/x86.
> > >
> > > Let me try convincing you that glibc should be fixed:)
> > >
> > >    // a.c
> > >    #include <stdio.h>
> > >
> > >    int a_impl() { return 42; }
> > >    void *a_resolver() {
> > >      puts("a_resolver");
> > >      return (void *)a_impl;
> > >    }
> > >    int a() __attribute__((ifunc("a_resolver")));
> > >
> > >    // .rela.dyn.rel => R_X86_64_64 referencing STT_GNU_IFUNC in .rela.dyn
> > >    int (*fptr_a)() = a;
> > >
> > >    int main() { printf("%d\n", a()); }
> > >
> > > OK, let's compile with gcc and link with GNU ld:
> > >
> > > % cc -fpie -c a.c; cc -fuse-ld=bfd -pie a.o -o a; ./a
> > > [1]    170657 segmentation fault  ./a
> > >
> > > Oops. The segfault is very similar to the 2 ld.lld FAIL.
> >
> > There are restrictions on how IFUNC can be used.   If we want to
> > support this use case, we need to change ld.so or/and linker.
>
> Since you are familiar with dynamic linking, perhaps you can offer the
> ld.so fix  (postponing ifunc resolver invocation after other regular
> relocations) :)

Please open a glibc bug so that we can track it.   We should first
decide if we want to support this use case.

> Once a separate relocation loop for ifunc is created, it is trivial
> for non-x86 arch maintainers to make ifunc more reliable for their
> arches.
>
> Then users can build more trust on ifunc.
>
>
> Let me consider this sub-thread a non-blocker for LLD 13.0.0 support.
>
> > > Now, you may say, we can change GNU ld to emit R_X86_64_IRELATIVE instead of R_X86_64_64.
> > >
> > > Then let's try this:
> > >
> > >    // b.c
> > >    #include <stdio.h>
> > >
> > >    int b_impl() { return 42; }
> > >    void *b_resolver() {
> > >      puts("b resolver");
> > >      return (void *)b_impl;
> > >    }
> > >    int b() __attribute__((ifunc("b_resolver")));
> > >
> > >    int (*fptr_b)() = b;
> > >
> > > cc b.c -fpic -shared -o b.so
> > > Make it a DT_NEEDED of a and see the crash again. b is preemptible so IRELATIVE is not correct.
> >
> > I don't believe this is the use case we want to support.
>
> Do we have easy-to-explain words on what's supported and what's not?

This has been a recurring topic. We should have some guidance
on IFUNC.  IFUNC was designed for glibc.  It was later extended to
other use cases.  There are limitations, like

https://sourceware.org/bugzilla/show_bug.cgi?id=20019

We need clear descriptions about how IFUNC should be used.

> > >
> > > If glibc adopts the FreeBSD model, then all these will be good, along with LLD's .rela.dyn IRELATIVE.
> > > An ifunc resolver can call functions defined in an arbitrary DT_NEEDED.
> >
> >
> >
> > --
> > H.J.



-- 
H.J.


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=2093.61128f89.59cc.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+%5BPATCH+v2+3%2F3%5D+configure%3A+Allow+LD+to+be+LLD+13.0.0+or+above+%5BBZ+%2326558%5D&verdict=C&c=0f09648365b0c17616257533dfe06e9233f5babe

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 13:49 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 13:49 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx409.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 464 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 20267 bytes --]

From: Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org>
To: Fangrui Song <maskray@google.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH] elf: Unconditionally use __ehdr_start
Date: Tue, 10 Aug 2021 14:48:50 +0100
Message-ID: <20210810134849.GI20410@arm.com>

The 08/06/2021 22:58, Fangrui Song via Libc-alpha wrote:
> We can consider __ehdr_start (from binutils 2.23 onwards)
> unconditionally supported, since configure.ac requires binutils>=2.25.
> 
> The configure.ac check is related to an ia64 bug fixed by binutils 2.24.
> See https://sourceware.org/pipermail/libc-alpha/2014-August/053503.html
> 
> Tested on x86_64-linux-gnu. Tested build-many-glibcs.py with
> aarch64-linux-gnu and s390x-linux-gnu.

this looks good.

Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>


> ---
>  config.h.in  |  3 ---
>  configure    | 52 ----------------------------------------------------
>  configure.ac | 34 ----------------------------------
>  elf/rtld.c   | 13 ++++---------
>  4 files changed, 4 insertions(+), 98 deletions(-)
> 
> diff --git a/config.h.in b/config.h.in
> index 8b45a3a61d..0d92504f65 100644
> --- a/config.h.in
> +++ b/config.h.in
> @@ -198,9 +198,6 @@
>  /* Define if CC supports attribute retain.  */
>  #undef HAVE_GNU_RETAIN
>  
> -/* Define if the linker defines __ehdr_start.  */
> -#undef HAVE_EHDR_START
> -
>  /* Define to 1 if the assembler needs intermediate aliases to define
>     multiple symbol versions for one symbol.  */
>  #define SYMVER_NEEDS_ALIAS 0
> diff --git a/configure b/configure
> index 9619c10991..7272fbf6ea 100755
> --- a/configure
> +++ b/configure
> @@ -6636,58 +6636,6 @@ if test $libc_cv_predef_fortify_source = yes; then
>  fi
>  
>  
> -# Some linkers on some architectures support __ehdr_start but with
> -# bugs.  Make sure usage of it does not create relocations in the
> -# output (as the linker should resolve them all for us).
> -{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether the linker provides working __ehdr_start" >&5
> -$as_echo_n "checking whether the linker provides working __ehdr_start... " >&6; }
> -if ${libc_cv_ehdr_start+:} false; then :
> -  $as_echo_n "(cached) " >&6
> -else
> -
> -old_CFLAGS="$CFLAGS"
> -old_LDFLAGS="$LDFLAGS"
> -old_LIBS="$LIBS"
> -CFLAGS="$CFLAGS -fPIC"
> -LDFLAGS="$LDFLAGS -nostdlib -nostartfiles -shared $no_ssp"
> -LIBS=
> -cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> -/* end confdefs.h.  */
> -
> -typedef struct {
> -  char foo;
> -  long val;
> -} Ehdr;
> -extern const Ehdr __ehdr_start __attribute__ ((visibility ("hidden")));
> -long ehdr (void) { return __ehdr_start.val; }
> -
> -_ACEOF
> -if ac_fn_c_try_link "$LINENO"; then :
> -  if $READELF -r conftest | grep -F __ehdr_start >/dev/null; then
> -		  libc_cv_ehdr_start=broken
> -		else
> -		  libc_cv_ehdr_start=yes
> -		fi
> -else
> -  libc_cv_ehdr_start=no
> -fi
> -rm -f core conftest.err conftest.$ac_objext \
> -    conftest$ac_exeext conftest.$ac_ext
> -CFLAGS="$old_CFLAGS"
> -LDFLAGS="$old_LDFLAGS"
> -LIBS="$old_LIBS"
> -
> -fi
> -{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_ehdr_start" >&5
> -$as_echo "$libc_cv_ehdr_start" >&6; }
> -if test "$libc_cv_ehdr_start" = yes; then
> -  $as_echo "#define HAVE_EHDR_START 1" >>confdefs.h
> -
> -elif test "$libc_cv_ehdr_start" = broken; then
> -  { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: linker is broken -- you should upgrade" >&5
> -$as_echo "$as_me: WARNING: linker is broken -- you should upgrade" >&2;}
> -fi
> -
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether the assembler requires one version per symbol" >&5
>  $as_echo_n "checking whether the assembler requires one version per symbol... " >&6; }
>  if ${libc_cv_symver_needs_alias+:} false; then :
> diff --git a/configure.ac b/configure.ac
> index 34ecbba540..af47cd51e6 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1662,40 +1662,6 @@ if test $libc_cv_predef_fortify_source = yes; then
>  fi
>  AC_SUBST(CPPUNDEFS)
>  
> -# Some linkers on some architectures support __ehdr_start but with
> -# bugs.  Make sure usage of it does not create relocations in the
> -# output (as the linker should resolve them all for us).
> -AC_CACHE_CHECK([whether the linker provides working __ehdr_start],
> -	       libc_cv_ehdr_start, [
> -old_CFLAGS="$CFLAGS"
> -old_LDFLAGS="$LDFLAGS"
> -old_LIBS="$LIBS"
> -CFLAGS="$CFLAGS -fPIC"
> -LDFLAGS="$LDFLAGS -nostdlib -nostartfiles -shared $no_ssp"
> -LIBS=
> -AC_LINK_IFELSE([AC_LANG_SOURCE([
> -typedef struct {
> -  char foo;
> -  long val;
> -} Ehdr;
> -extern const Ehdr __ehdr_start __attribute__ ((visibility ("hidden")));
> -long ehdr (void) { return __ehdr_start.val; }
> -])],
> -	       [if $READELF -r conftest | grep -F __ehdr_start >/dev/null; then
> -		  libc_cv_ehdr_start=broken
> -		else
> -		  libc_cv_ehdr_start=yes
> -		fi], [libc_cv_ehdr_start=no])
> -CFLAGS="$old_CFLAGS"
> -LDFLAGS="$old_LDFLAGS"
> -LIBS="$old_LIBS"
> -])
> -if test "$libc_cv_ehdr_start" = yes; then
> -  AC_DEFINE([HAVE_EHDR_START])
> -elif test "$libc_cv_ehdr_start" = broken; then
> -  AC_MSG_WARN([linker is broken -- you should upgrade])
> -fi
> -
>  dnl Starting with binutils 2.35, GAS can attach multiple symbol versions
>  dnl to one symbol (PR 23840).
>  AC_CACHE_CHECK(whether the assembler requires one version per symbol,
> diff --git a/elf/rtld.c b/elf/rtld.c
> index d733359eaf..878e6480f4 100644
> --- a/elf/rtld.c
> +++ b/elf/rtld.c
> @@ -1684,21 +1684,16 @@ dl_main (const ElfW(Phdr) *phdr,
>    if (GLRO(dl_use_load_bias) == (ElfW(Addr)) -2)
>      GLRO(dl_use_load_bias) = main_map->l_addr == 0 ? -1 : 0;
>  
> -  /* Set up the program header information for the dynamic linker
> -     itself.  It is needed in the dl_iterate_phdr callbacks.  */
> -  const ElfW(Ehdr) *rtld_ehdr;
> -
>    /* Starting from binutils-2.23, the linker will define the magic symbol
>       __ehdr_start to point to our own ELF header if it is visible in a
>       segment that also includes the phdrs.  If that's not available, we use
>       the old method that assumes the beginning of the file is part of the
>       lowest-addressed PT_LOAD segment.  */
> -#ifdef HAVE_EHDR_START
>    extern const ElfW(Ehdr) __ehdr_start __attribute__ ((visibility ("hidden")));
> -  rtld_ehdr = &__ehdr_start;
> -#else
> -  rtld_ehdr = (void *) GL(dl_rtld_map).l_map_start;
> -#endif
> +
> +  /* Set up the program header information for the dynamic linker
> +     itself.  It is needed in the dl_iterate_phdr callbacks.  */
> +  const ElfW(Ehdr) *rtld_ehdr = &__ehdr_start;
>    assert (rtld_ehdr->e_ehsize == sizeof *rtld_ehdr);
>    assert (rtld_ehdr->e_phentsize == sizeof (ElfW(Phdr)));
>  
> -- 
> 2.32.0.605.g8dce9f2422-goog
> 


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=99ec.611283ea.9f5a5.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+%5BPATCH%5D+elf%3A+Unconditionally+use+__ehdr_start&verdict=C&c=190ae7b1e4a50ded7b4819d47ab1ff90d7603931

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 13:34 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 13:34 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx405.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 464 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 6647 bytes --]

From: "H.J. Lu via Libc-alpha" <libc-alpha@sourceware.org>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [RFC][PATCH v12 4/8] Add DT_GNU_FLAGS_1/DF_GNU_1_UNIQUE to glibc DSOs (bug 22745)
Date: Tue, 10 Aug 2021 06:32:32 -0700
Message-ID: <CAMe9rOriyBVeQ-dZb-Rx=7shXxAB-od+XfomWuhZd6TAQ-1JEw@mail.gmail.com>

On Tue, Aug 10, 2021 at 6:21 AM Adhemerval Zanella via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> There are a couple of minor issues that prevent the -Wl,-z,unique usage.
> It does not change the build outcome because the the unique GNU_FLAGS_1
> will be added by elf/dynamic-notes.os anyway.
>
> > On 08/07/2021 13:32, Vivek Das Mohapatra via Libc-alpha wrote:
> >> diff --git a/config.make.in b/config.make.in
> >> index cbf59114b0..8755490c13 100644
> >> --- a/config.make.in
> >> +++ b/config.make.in
> >> @@ -72,6 +72,7 @@ have-cc-with-libunwind = @libc_cv_cc_with_libunwind@
> >>  fno-unit-at-a-time = @fno_unit_at_a_time@
> >>  bind-now = @bindnow@
> >>  have-hash-style = @libc_cv_hashstyle@
> >> +ld-zunique = @ld_zunique@

No need for this.  Please use LIBC_CONFIG_VAR.

> This is wrong, it should be '@libc_cv_ld_zunique@'
>
> >> diff --git a/configure.ac b/configure.ac
> >> index 34ecbba540..9369bcbebe 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -1372,9 +1372,28 @@ fi
> >>  rm -f conftest*])
> >>  AC_SUBST(libc_cv_hashstyle)
> >>
> >> +AC_CACHE_CHECK([for linker DT_GNU_FLAGS_1/ DF_GNU_1_UNIQUE support],
> >
> > Maybe a space before ' /'.
> >
> >> +                libc_cv_ld_zunique, [dnl
> >> +cat > conftest.ld.c <<\EOF
> >> +int x (void) { return 0; }
> >> +EOF
> >> +
> >> +libc_cv_ld_zunique=no;
> >> +
> >> +if AC_TRY_COMMAND([dnl
> >> +${CC-cc} -Wl,--fatal-warnings -Wl,-z,unique -shared -o conftest.ld.so conftest.ld.c])
> >> +then
> >> +  libc_cv_ld_zunique=yes
> >> +fi;
> >> +ld_zunique=$libc_cv_ld_zunique
> >> +rm -f conftest*])
> >> +AC_SUBST(ld_zunique)
>
> This is wrong, it should be AC_SUBST(libc_cv_ld_zunique).



-- 
H.J.


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=c0df.6112802e.9dbe4.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+%5BRFC%5D%5BPATCH+v12+4%2F8%5D+Add+DT_GNU_FLAGS_1%2FDF_GNU_1_UNIQUE+to+glibc+DSOs+%28bug+22745%29&verdict=C&c=15a8a4f7abb070b01af4ee45b8cf1cd7bcf0da11

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 13:21 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 13:21 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx301.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 465 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 6731 bytes --]

From: Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org>
To: libc-alpha@sourceware.org, Vivek Das Mohapatra <vivek@collabora.com>
Subject: Re: [RFC][PATCH v12 4/8] Add DT_GNU_FLAGS_1/DF_GNU_1_UNIQUE to glibc DSOs (bug 22745)
Date: Tue, 10 Aug 2021 10:21:04 -0300
Message-ID: <bce48876-3474-99ce-3fdf-40ddc0be0bc1@linaro.org>

There are a couple of minor issues that prevent the -Wl,-z,unique usage.
It does not change the build outcome because the the unique GNU_FLAGS_1
will be added by elf/dynamic-notes.os anyway.

> On 08/07/2021 13:32, Vivek Das Mohapatra via Libc-alpha wrote:
>> diff --git a/config.make.in b/config.make.in
>> index cbf59114b0..8755490c13 100644
>> --- a/config.make.in
>> +++ b/config.make.in
>> @@ -72,6 +72,7 @@ have-cc-with-libunwind = @libc_cv_cc_with_libunwind@
>>  fno-unit-at-a-time = @fno_unit_at_a_time@
>>  bind-now = @bindnow@
>>  have-hash-style = @libc_cv_hashstyle@
>> +ld-zunique = @ld_zunique@

This is wrong, it should be '@libc_cv_ld_zunique@'
 
>> diff --git a/configure.ac b/configure.ac
>> index 34ecbba540..9369bcbebe 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -1372,9 +1372,28 @@ fi
>>  rm -f conftest*])
>>  AC_SUBST(libc_cv_hashstyle)
>>  
>> +AC_CACHE_CHECK([for linker DT_GNU_FLAGS_1/ DF_GNU_1_UNIQUE support],
> 
> Maybe a space before ' /'.
> 
>> +                libc_cv_ld_zunique, [dnl
>> +cat > conftest.ld.c <<\EOF
>> +int x (void) { return 0; }
>> +EOF
>> +
>> +libc_cv_ld_zunique=no;
>> +
>> +if AC_TRY_COMMAND([dnl
>> +${CC-cc} -Wl,--fatal-warnings -Wl,-z,unique -shared -o conftest.ld.so conftest.ld.c])
>> +then
>> +  libc_cv_ld_zunique=yes
>> +fi;
>> +ld_zunique=$libc_cv_ld_zunique
>> +rm -f conftest*])
>> +AC_SUBST(ld_zunique)

This is wrong, it should be AC_SUBST(libc_cv_ld_zunique).


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=702f.61127d5e.afbf6.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+%5BRFC%5D%5BPATCH+v12+4%2F8%5D+Add+DT_GNU_FLAGS_1%2FDF_GNU_1_UNIQUE+to+glibc+DSOs+%28bug+22745%29&verdict=C&c=183e3c2d9f2f21d22ddbc40061b7298039d3cebd

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 13:02 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 13:02 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx302.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 465 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 10827 bytes --]

From: Romain GEISSLER via Libc-alpha <libc-alpha@sourceware.org>
To: libc-alpha@sourceware.org
Subject: [PATCH] Fix tst-canon-bz26341 when the glibc build current working directory is itself using symlinks
Date: Tue, 10 Aug 2021 13:01:28 +0000
Message-ID: <20210810130121.GA62219@ncerndobedev6097.etv.nce.amadeus.net>

Hi,

I am seeing test failures with tst-canon-bz26341. Using strace I found out that
the problem comes from when change the current working directory to my glibc build
directory, I use a path with is using itself symlinks. So at the beginning of the
test the "filename" variable needs to be canonicalized properly to make it pass in
these conditions.

Tested on x86-64.

Cheers,
Romain

From 99ef44560977e366c64912cfcb2a6535a0614c50 Mon Sep 17 00:00:00 2001
From: Romain Geissler <romain.geissler@amadeus.com>
Date: Tue, 10 Aug 2021 12:40:41 +0000
Subject: [PATCH] Fix tst-canon-bz26341 when the glibc build current working
 directory is itself using symlinks.

---
 stdlib/tst-canon-bz26341.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/stdlib/tst-canon-bz26341.c b/stdlib/tst-canon-bz26341.c
index acb0fd4ec30..171ec0dc45a 100644
--- a/stdlib/tst-canon-bz26341.c
+++ b/stdlib/tst-canon-bz26341.c
@@ -45,6 +45,12 @@ create_link (void)
   TEST_VERIFY_EXIT (fd != -1);
   xclose (fd);
 
+  /* Make filename a canonical path. */
+  char *saved_filename = filename;
+  filename = realpath (filename, NULL);
+  free (saved_filename);
+  TEST_VERIFY (filename != NULL);
+
   /* Create MAXLINKS symbolic links to the temporary filename.
      On exit, linkname has the last link created.  */
   char *prevlink = filename;
-- 
2.25.1


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=16ae0.611278c5.ab3e.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=%5BPATCH%5D+Fix+tst-canon-bz26341+when+the+glibc+build+current+working+directory+is+itself+using+symlinks&verdict=C&c=eb46e89662c9471805eac12a83e870f1df8a9415

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10 11:20 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10 11:20 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx601.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 464 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 16640 bytes --]

From: Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org>
To: Fangrui Song <maskray@google.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH] aarch64: Skip traditional GD/LD TLS which are unsupported by Clang and LLD [BZ #28205]
Date: Tue, 10 Aug 2021 12:20:03 +0100
Message-ID: <20210810112002.GH20410@arm.com>

The 08/06/2021 15:41, Fangrui Song via Libc-alpha wrote:
> TLSDESC is the default on aarch64.  Clang doesn't support
> -mtls-dialect=trad.  Its integrated assembler doesn't support the
> marker.  LLD's doesn't support R_AARCH64_TLSGD_*/R_AARCH64_TLSLD_*
> relocations.  Just skip the tests.
> 
> With https://sourceware.org/pipermail/libc-alpha/2021-August/129904.html
> ("aarch64: Make elf_machine_{load_address, dynamic} robust [BZ #28203]"),
> if we allow LLD in configure.ac,
> `make check` test results of LLD are on par with GNU ld.
> ---
>  config.h.in       |  3 +++
>  configure         | 38 ++++++++++++++++++++++++++++++++++++++
>  configure.ac      | 24 ++++++++++++++++++++++++
>  elf/tst-tls1.c    |  7 +++++--
>  elf/tst-tls2.c    |  6 ++++--
>  elf/tst-tls3.c    |  8 ++++----
>  elf/tst-tlsmod1.c |  6 ++++--
>  elf/tst-tlsmod2.c |  4 +++-
>  elf/tst-tlsmod3.c |  5 ++++-
>  elf/tst-tlsmod4.c |  4 +++-
>  10 files changed, 92 insertions(+), 13 deletions(-)
> 
> diff --git a/config.h.in b/config.h.in
> index 8b45a3a61d..f65605d4bd 100644
> --- a/config.h.in
> +++ b/config.h.in
> @@ -198,6 +198,9 @@
>  /* Define if CC supports attribute retain.  */
>  #undef HAVE_GNU_RETAIN
>  
> +/* Define if CC and LD support -mtls-dialect=trad.  */
> +#undef HAVE_MTLS_DIALECT_TRAD
> +
>  /* Define if the linker defines __ehdr_start.  */
>  #undef HAVE_EHDR_START
>  
> diff --git a/configure.ac b/configure.ac
> index 5632277f9c..c73e271cc8 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1501,6 +1501,30 @@ rm -f conftest*])
>  AC_SUBST(libc_cv_mtls_dialect_gnu2)
>  LIBC_CONFIG_VAR([have-mtls-dialect-gnu2], [$libc_cv_mtls_dialect_gnu2])
>  
> +AC_CACHE_CHECK([for -mtls-dialect=trad], libc_cv_mtls_dialect_trad,
> +[dnl
> +cat > conftest.c <<EOF
> +extern __thread int i;
> +void foo (void)
> +{
> +  i = 10;
> +}
> +EOF
> +if AC_TRY_COMMAND([${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS
> +			-fPIC -mtls-dialect=trad -shared -o conftest.so conftest.c
> +			1>&AS_MESSAGE_LOG_FD])
> +then
> +  libc_cv_mtls_dialect_trad=yes
> +else
> +  libc_cv_mtls_dialect_trad=no
> +fi
> +rm -f conftest*])
> +if test $libc_cv_mtls_dialect_trad = yes; then
> +  AC_DEFINE(HAVE_MTLS_DIALECT_TRAD)
> +fi
> +AC_SUBST(libc_cv_mtls_dialect_trad)
> +LIBC_CONFIG_VAR([have-mtls-dialect-trad], [$libc_cv_mtls_dialect_trad])

this is a possible way, but i think it's nicer to have

#define HAVE_TRAD_TLS 1

in config.h.in, and then in sysdeps/aarch64/configure.ac

AC_DEFINE(HAVE_TRAD_TLS, 0, [Only TLSDESC is supported])

(haven't tested, but i think it would work)

(-mtls-dialect=trad is aarch64 specific flag, so it's
not nice in the generic configure and the tests don't
actually care about this flag but whether the assembler
and linker would work)




To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=18285.61126110.e342.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+%5BPATCH%5D+aarch64%3A+Skip+traditional+GD%2FLD+TLS+which+are+unsupported+by+Clang+and+LLD+%5BBZ+%2328205%5D&verdict=C&c=7b500cf3e0f21e2ea99809f1c52675f6d35ba951

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10  9:45 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10  9:45 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx302.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 465 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 16414 bytes --]

From: Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org>
To: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Cc: 'GNU C Library' <libc-alpha@sourceware.org>
Subject: Re: [PATCH v4 5/5] AArch64: Improve A64FX memset medium loops
Date: Tue, 10 Aug 2021 10:44:29 +0100
Message-ID: <20210810094428.GG20410@arm.com>

The 08/09/2021 13:15, Wilco Dijkstra via Libc-alpha wrote:
> v4: minor loop change
> 
> Simplify the code for memsets smaller than L1. Improve the unroll8 and L1_prefetch loops.

OK to commit, but keep

Reviewed-by: Naohiro Tamura <naohirot@fujitsu.com>

(further tweaks can go into follwup commits.)

> 
> ---
> 
> diff --git a/sysdeps/aarch64/multiarch/memset_a64fx.S b/sysdeps/aarch64/multiarch/memset_a64fx.S
> index 89dba912588c243e67a9527a56b4d3a44659d542..318c6350a31e0fad788b5f2139de645ddc51493f 100644
> --- a/sysdeps/aarch64/multiarch/memset_a64fx.S
> +++ b/sysdeps/aarch64/multiarch/memset_a64fx.S
> @@ -30,7 +30,6 @@
>  #define L2_SIZE         (8*1024*1024)	// L2 8MB
>  #define CACHE_LINE_SIZE	256
>  #define PF_DIST_L1	(CACHE_LINE_SIZE * 16)	// Prefetch distance L1
> -#define rest		x2
>  #define vector_length	x9
>  
>  #if HAVE_AARCH64_SVE_ASM
> @@ -89,29 +88,19 @@ ENTRY (MEMSET)
>  
>  	.p2align 4
>  L(vl_agnostic): // VL Agnostic
> -	mov	rest, count
>  	mov	dst, dstin
> -	add	dstend, dstin, count
> -	// if rest >= L2_SIZE && vector_length == 64 then L(L2)
> -	mov	tmp1, 64
> -	cmp	rest, L2_SIZE
> -	ccmp	vector_length, tmp1, 0, cs
> -	b.eq	L(L2)
> -	// if rest >= L1_SIZE && vector_length == 64 then L(L1_prefetch)
> -	cmp	rest, L1_SIZE
> -	ccmp	vector_length, tmp1, 0, cs
> -	b.eq	L(L1_prefetch)
> -
> +	cmp	count, L1_SIZE
> +	b.hi	L(L1_prefetch)
>  
> +	// count >= 8 * vector_length
>  L(unroll8):
> -	lsl	tmp1, vector_length, 3
> -	.p2align 3
> -1:	cmp	rest, tmp1
> -	b.cc	L(last)
> -	st1b_unroll
> +	sub	count, count, tmp1
> +	.p2align 4
> +1:	st1b_unroll 0, 7
>  	add	dst, dst, tmp1
> -	sub	rest, rest, tmp1
> -	b	1b
> +	subs	count, count, tmp1
> +	b.hi	1b
> +	add	count, count, tmp1
>  
>  L(last):
>  	cmp	count, vector_length, lsl 1
> @@ -129,18 +118,22 @@ L(last):
>  	st1b	z0.b, p0, [dstend, -1, mul vl]
>  	ret
>  
> -L(L1_prefetch): // if rest >= L1_SIZE
> +	// count >= L1_SIZE
>  	.p2align 3
> +L(L1_prefetch):
> +	cmp	count, L2_SIZE
> +	b.hs	L(L2)
> +	cmp	vector_length, 64
> +	b.ne	L(unroll8)
>  1:	st1b_unroll 0, 3
>  	prfm	pstl1keep, [dst, PF_DIST_L1]
>  	st1b_unroll 4, 7
>  	prfm	pstl1keep, [dst, PF_DIST_L1 + CACHE_LINE_SIZE]
>  	add	dst, dst, CACHE_LINE_SIZE * 2
> -	sub	rest, rest, CACHE_LINE_SIZE * 2
> -	cmp	rest, L1_SIZE
> -	b.ge	1b
> -	cbnz	rest, L(unroll8)
> -	ret
> +	sub	count, count, CACHE_LINE_SIZE * 2
> +	cmp	count, PF_DIST_L1
> +	b.hs	1b
> +	b	L(unroll8)
>  
>  	// count >= L2_SIZE
>  	.p2align 3
> 

-- 


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=115e1.61124ad0.1ab59.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+%5BPATCH+v4+5%2F5%5D+AArch64%3A+Improve+A64FX+memset+medium+loops&verdict=C&c=f39d9cf9bc2bf4b6b9ed72b252e2bb740f50c51b

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10  9:44 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10  9:44 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx408.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 465 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 15102 bytes --]

From: Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org>
To: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Cc: 'GNU C Library' <libc-alpha@sourceware.org>
Subject: Re: [PATCH v4 4/5] AArch64: Improve A64FX memset by removing unroll32
Date: Tue, 10 Aug 2021 10:43:11 +0100
Message-ID: <20210810094310.GF20410@arm.com>

The 08/09/2021 13:13, Wilco Dijkstra via Libc-alpha wrote:
> v4: no changes
> 
> Remove unroll32 code since it doesn't improve performance.

OK to commit, but keep

Reviewed-by: Naohiro Tamura <naohirot@fujitsu.com>

> 
> ---
> 
> diff --git a/sysdeps/aarch64/multiarch/memset_a64fx.S b/sysdeps/aarch64/multiarch/memset_a64fx.S
> index 55f28b644defdffb140c88da0635ef099235546c..89dba912588c243e67a9527a56b4d3a44659d542 100644
> --- a/sysdeps/aarch64/multiarch/memset_a64fx.S
> +++ b/sysdeps/aarch64/multiarch/memset_a64fx.S
> @@ -102,22 +102,6 @@ L(vl_agnostic): // VL Agnostic
>  	ccmp	vector_length, tmp1, 0, cs
>  	b.eq	L(L1_prefetch)
>  
> -L(unroll32):
> -	lsl	tmp1, vector_length, 3	// vector_length * 8
> -	lsl	tmp2, vector_length, 5	// vector_length * 32
> -	.p2align 3
> -1:	cmp	rest, tmp2
> -	b.cc	L(unroll8)
> -	st1b_unroll
> -	add	dst, dst, tmp1
> -	st1b_unroll
> -	add	dst, dst, tmp1
> -	st1b_unroll
> -	add	dst, dst, tmp1
> -	st1b_unroll
> -	add	dst, dst, tmp1
> -	sub	rest, rest, tmp2
> -	b	1b
>  
>  L(unroll8):
>  	lsl	tmp1, vector_length, 3
> @@ -155,7 +139,7 @@ L(L1_prefetch): // if rest >= L1_SIZE
>  	sub	rest, rest, CACHE_LINE_SIZE * 2
>  	cmp	rest, L1_SIZE
>  	b.ge	1b
> -	cbnz	rest, L(unroll32)
> +	cbnz	rest, L(unroll8)
>  	ret
>  
>  	// count >= L2_SIZE
> 

-- 


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=64d6.61124a6e.75f22.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+%5BPATCH+v4+4%2F5%5D+AArch64%3A+Improve+A64FX+memset+by+removing+unroll32&verdict=C&c=6365b380ef727a64bd2846632cf6f1bb36967e09

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10  9:41 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10  9:41 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx408.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 465 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 16259 bytes --]

From: Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org>
To: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Cc: 'GNU C Library' <libc-alpha@sourceware.org>
Subject: Re: [PATCH v4 3/5] AArch64: Improve A64FX memset for remaining bytes
Date: Tue, 10 Aug 2021 10:39:19 +0100
Message-ID: <20210810093918.GE20410@arm.com>

The 08/09/2021 13:11, Wilco Dijkstra via Libc-alpha wrote:
> v4: no changes
> 
> Simplify handling of remaining bytes. Avoid lots of taken branches and complex
> whilelo computations, instead unconditionally write vectors from the end.

OK for commit, but keep

Reviewed-by: Naohiro Tamura <naohirot@fujitsu.com>

> 
> ---
> 
> diff --git a/sysdeps/aarch64/multiarch/memset_a64fx.S b/sysdeps/aarch64/multiarch/memset_a64fx.S
> index 6bc8ef5e0c84dbb59a57d114ae6ec8e3fa3822ad..55f28b644defdffb140c88da0635ef099235546c 100644
> --- a/sysdeps/aarch64/multiarch/memset_a64fx.S
> +++ b/sysdeps/aarch64/multiarch/memset_a64fx.S
> @@ -130,38 +130,19 @@ L(unroll8):
>  	b	1b
>  
>  L(last):
> -	whilelo	p0.b, xzr, rest
> -	whilelo	p1.b, vector_length, rest
> -	b.last	1f
> -	st1b	z0.b, p0, [dst, #0, mul vl]
> -	st1b	z0.b, p1, [dst, #1, mul vl]
> -	ret
> -1:	lsl	tmp1, vector_length, 1	// vector_length * 2
> -	whilelo	p2.b, tmp1, rest
> -	incb	tmp1
> -	whilelo	p3.b, tmp1, rest
> -	b.last	1f
> -	st1b	z0.b, p0, [dst, #0, mul vl]
> -	st1b	z0.b, p1, [dst, #1, mul vl]
> -	st1b	z0.b, p2, [dst, #2, mul vl]
> -	st1b	z0.b, p3, [dst, #3, mul vl]
> -	ret
> -1:	lsl	tmp1, vector_length, 2	// vector_length * 4
> -	whilelo	p4.b, tmp1, rest
> -	incb	tmp1
> -	whilelo	p5.b, tmp1, rest
> -	incb	tmp1
> -	whilelo	p6.b, tmp1, rest
> -	incb	tmp1
> -	whilelo	p7.b, tmp1, rest
> -	st1b	z0.b, p0, [dst, #0, mul vl]
> -	st1b	z0.b, p1, [dst, #1, mul vl]
> -	st1b	z0.b, p2, [dst, #2, mul vl]
> -	st1b	z0.b, p3, [dst, #3, mul vl]
> -	st1b	z0.b, p4, [dst, #4, mul vl]
> -	st1b	z0.b, p5, [dst, #5, mul vl]
> -	st1b	z0.b, p6, [dst, #6, mul vl]
> -	st1b	z0.b, p7, [dst, #7, mul vl]
> +	cmp	count, vector_length, lsl 1
> +	b.ls	2f
> +	add	tmp2, vector_length, vector_length, lsl 2
> +	cmp	count, tmp2
> +	b.ls	5f
> +	st1b	z0.b, p0, [dstend, -8, mul vl]
> +	st1b	z0.b, p0, [dstend, -7, mul vl]
> +	st1b	z0.b, p0, [dstend, -6, mul vl]
> +5:	st1b	z0.b, p0, [dstend, -5, mul vl]
> +	st1b	z0.b, p0, [dstend, -4, mul vl]
> +	st1b	z0.b, p0, [dstend, -3, mul vl]
> +2:	st1b	z0.b, p0, [dstend, -2, mul vl]
> +	st1b	z0.b, p0, [dstend, -1, mul vl]
>  	ret
>  
>  L(L1_prefetch): // if rest >= L1_SIZE
> @@ -199,7 +180,6 @@ L(L2):
>  	subs	count, count, CACHE_LINE_SIZE
>  	b.hi	1b
>  	add	count, count, CACHE_LINE_SIZE
> -	add	dst, dst, CACHE_LINE_SIZE
>  	b	L(last)
>  
>  END (MEMSET)

-- 


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=44b2.611249b0.e8ef7.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+%5BPATCH+v4+3%2F5%5D+AArch64%3A+Improve+A64FX+memset+for+remaining+bytes&verdict=C&c=ae14db95615ab43d946fab7b4a97f9972c3011dd

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10  9:39 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10  9:39 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx601.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 464 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 17779 bytes --]

From: Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org>
To: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Cc: 'GNU C Library' <libc-alpha@sourceware.org>
Subject: Re: [PATCH v4 2/5] AArch64: Improve A64FX memset for large sizes
Date: Tue, 10 Aug 2021 10:38:31 +0100
Message-ID: <20210810093830.GD20410@arm.com>

The 08/09/2021 16:17, Wilco Dijkstra via Libc-alpha wrote:
> v4: Slightly tweak alignment code
> 
> Improve performance of large memsets. Simplify alignment code. For zero memset use DC ZVA,
> which almost doubles performance. For non-zero memsets use the unroll8 loop which is about 10% faster.


this is OK to commit.

you should keep

Reviewed-by: Naohiro Tamura <naohirot@fujitsu.com>

in the commit message if there are only minor tweaks or no changes.

> 
> ---
> 
> diff --git a/sysdeps/aarch64/multiarch/memset_a64fx.S b/sysdeps/aarch64/multiarch/memset_a64fx.S
> index cf3d402ef681a9d98964d1751537945692a1ae68..6bc8ef5e0c84dbb59a57d114ae6ec8e3fa3822ad 100644
> --- a/sysdeps/aarch64/multiarch/memset_a64fx.S
> +++ b/sysdeps/aarch64/multiarch/memset_a64fx.S
> @@ -27,14 +27,11 @@
>   */
>  
>  #define L1_SIZE		(64*1024)	// L1 64KB
> -#define L2_SIZE         (8*1024*1024)	// L2 8MB - 1MB
> +#define L2_SIZE         (8*1024*1024)	// L2 8MB
>  #define CACHE_LINE_SIZE	256
>  #define PF_DIST_L1	(CACHE_LINE_SIZE * 16)	// Prefetch distance L1
> -#define ZF_DIST		(CACHE_LINE_SIZE * 21)	// Zerofill distance
> -#define rest		x8
> +#define rest		x2
>  #define vector_length	x9
> -#define vl_remainder	x10	// vector_length remainder
> -#define cl_remainder	x11	// CACHE_LINE_SIZE remainder
>  
>  #if HAVE_AARCH64_SVE_ASM
>  # if IS_IN (libc)
> @@ -42,14 +39,6 @@
>  
>  	.arch armv8.2-a+sve
>  
> -	.macro dc_zva times
> -	dc	zva, tmp1
> -	add	tmp1, tmp1, CACHE_LINE_SIZE
> -	.if \times-1
> -	dc_zva "(\times-1)"
> -	.endif
> -	.endm
> -
>  	.macro st1b_unroll first=0, last=7
>  	st1b	z0.b, p0, [dst, \first, mul vl]
>  	.if \last-\first
> @@ -188,54 +177,30 @@ L(L1_prefetch): // if rest >= L1_SIZE
>  	cbnz	rest, L(unroll32)
>  	ret
>  
> -L(L2):
> -	// align dst address at vector_length byte boundary
> -	sub	tmp1, vector_length, 1
> -	ands	tmp2, dst, tmp1
> -	// if vl_remainder == 0
> -	b.eq	1f
> -	sub	vl_remainder, vector_length, tmp2
> -	// process remainder until the first vector_length boundary
> -	whilelt	p2.b, xzr, vl_remainder
> -	st1b	z0.b, p2, [dst]
> -	add	dst, dst, vl_remainder
> -	sub	rest, rest, vl_remainder
> -	// align dstin address at CACHE_LINE_SIZE byte boundary
> -1:	mov	tmp1, CACHE_LINE_SIZE
> -	ands	tmp2, dst, CACHE_LINE_SIZE - 1
> -	// if cl_remainder == 0
> -	b.eq	L(L2_dc_zva)
> -	sub	cl_remainder, tmp1, tmp2
> -	// process remainder until the first CACHE_LINE_SIZE boundary
> -	mov	tmp1, xzr       // index
> -2:	whilelt	p2.b, tmp1, cl_remainder
> -	st1b	z0.b, p2, [dst, tmp1]
> -	incb	tmp1
> -	cmp	tmp1, cl_remainder
> -	b.lo	2b
> -	add	dst, dst, cl_remainder
> -	sub	rest, rest, cl_remainder
> -
> -L(L2_dc_zva):
> -	// zero fill
> -	mov	tmp1, dst
> -	dc_zva	(ZF_DIST / CACHE_LINE_SIZE) - 1
> -	mov	zva_len, ZF_DIST
> -	add	tmp1, zva_len, CACHE_LINE_SIZE * 2
> -	// unroll
> +	// count >= L2_SIZE
>  	.p2align 3
> -1:	st1b_unroll 0, 3
> -	add	tmp2, dst, zva_len
> -	dc	 zva, tmp2
> -	st1b_unroll 4, 7
> -	add	tmp2, tmp2, CACHE_LINE_SIZE
> -	dc	zva, tmp2
> -	add	dst, dst, CACHE_LINE_SIZE * 2
> -	sub	rest, rest, CACHE_LINE_SIZE * 2
> -	cmp	rest, tmp1	// ZF_DIST + CACHE_LINE_SIZE * 2
> -	b.ge	1b
> -	cbnz	rest, L(unroll8)
> -	ret
> +L(L2):
> +	tst	valw, 255
> +	b.ne	L(unroll8)
> +	// align dst to CACHE_LINE_SIZE byte boundary
> +	and	tmp2, dst, CACHE_LINE_SIZE - 1
> +	st1b	z0.b, p0, [dst, 0, mul vl]
> +	st1b	z0.b, p0, [dst, 1, mul vl]
> +	st1b	z0.b, p0, [dst, 2, mul vl]
> +	st1b	z0.b, p0, [dst, 3, mul vl]
> +	sub	dst, dst, tmp2
> +	add	count, count, tmp2
> +
> +	// clear cachelines using DC ZVA
> +	sub	count, count, CACHE_LINE_SIZE * 2
> +	.p2align 4
> +1:	add	dst, dst, CACHE_LINE_SIZE
> +	dc	zva, dst
> +	subs	count, count, CACHE_LINE_SIZE
> +	b.hi	1b
> +	add	count, count, CACHE_LINE_SIZE
> +	add	dst, dst, CACHE_LINE_SIZE
> +	b	L(last)
>  
>  END (MEMSET)
>  libc_hidden_builtin_def (MEMSET)
> 

-- 


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=1101e.6112494e.4d6f3.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+%5BPATCH+v4+2%2F5%5D+AArch64%3A+Improve+A64FX+memset+for+large+sizes&verdict=C&c=7c105351eee0d1e6a135ee26aa59282aa1476ba2

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Undelivered Mail Returned to Sender
@ 2021-08-10  9:37 MAILER-DAEMON
  0 siblings, 0 replies; 27+ messages in thread
From: MAILER-DAEMON @ 2021-08-10  9:37 UTC (permalink / raw)
  To: libc-alpha

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx409.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 464 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 17679 bytes --]

From: Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org>
To: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Cc: 'GNU C Library' <libc-alpha@sourceware.org>
Subject: Re: [PATCH v4 1/5] AArch64: Improve A64FX memset for small sizes
Date: Tue, 10 Aug 2021 10:36:53 +0100
Message-ID: <20210810093652.GC20410@arm.com>

The 08/09/2021 13:07, Wilco Dijkstra via Libc-alpha wrote:
> v4: Don't remove ZF_DIST yet
> 
> Improve performance of small memsets by reducing instruction counts and improving
> alignment. Bench-memset shows 35-45% performance gain for small sizes.

thanks, this is OK to commit.

(if further tweaks needed that can be in follow up commits)

> 
> ---
> 
> diff --git a/sysdeps/aarch64/multiarch/memset_a64fx.S b/sysdeps/aarch64/multiarch/memset_a64fx.S
> index ce54e5418b08c8bc0ecc7affff68a59272ba6397..cf3d402ef681a9d98964d1751537945692a1ae68 100644
> --- a/sysdeps/aarch64/multiarch/memset_a64fx.S
> +++ b/sysdeps/aarch64/multiarch/memset_a64fx.S
> @@ -51,78 +51,54 @@
>  	.endm
>  
>  	.macro st1b_unroll first=0, last=7
> -	st1b	z0.b, p0, [dst, #\first, mul vl]
> +	st1b	z0.b, p0, [dst, \first, mul vl]
>  	.if \last-\first
>  	st1b_unroll "(\first+1)", \last
>  	.endif
>  	.endm
>  
> -	.macro shortcut_for_small_size exit
> -	// if rest <= vector_length * 2
> -	whilelo	p0.b, xzr, count
> -	whilelo	p1.b, vector_length, count
> -	b.last	1f
> -	st1b	z0.b, p0, [dstin, #0, mul vl]
> -	st1b	z0.b, p1, [dstin, #1, mul vl]
> -	ret
> -1:	// if rest > vector_length * 8
> -	cmp	count, vector_length, lsl 3	// vector_length * 8
> -	b.hi	\exit
> -	// if rest <= vector_length * 4
> -	lsl	tmp1, vector_length, 1	// vector_length * 2
> -	whilelo	p2.b, tmp1, count
> -	incb	tmp1
> -	whilelo	p3.b, tmp1, count
> -	b.last	1f
> -	st1b	z0.b, p0, [dstin, #0, mul vl]
> -	st1b	z0.b, p1, [dstin, #1, mul vl]
> -	st1b	z0.b, p2, [dstin, #2, mul vl]
> -	st1b	z0.b, p3, [dstin, #3, mul vl]
> -	ret
> -1:	// if rest <= vector_length * 8
> -	lsl	tmp1, vector_length, 2	// vector_length * 4
> -	whilelo	p4.b, tmp1, count
> -	incb	tmp1
> -	whilelo	p5.b, tmp1, count
> -	b.last	1f
> -	st1b	z0.b, p0, [dstin, #0, mul vl]
> -	st1b	z0.b, p1, [dstin, #1, mul vl]
> -	st1b	z0.b, p2, [dstin, #2, mul vl]
> -	st1b	z0.b, p3, [dstin, #3, mul vl]
> -	st1b	z0.b, p4, [dstin, #4, mul vl]
> -	st1b	z0.b, p5, [dstin, #5, mul vl]
> -	ret
> -1:	lsl	tmp1, vector_length, 2	// vector_length * 4
> -	incb	tmp1			// vector_length * 5
> -	incb	tmp1			// vector_length * 6
> -	whilelo	p6.b, tmp1, count
> -	incb	tmp1
> -	whilelo	p7.b, tmp1, count
> -	st1b	z0.b, p0, [dstin, #0, mul vl]
> -	st1b	z0.b, p1, [dstin, #1, mul vl]
> -	st1b	z0.b, p2, [dstin, #2, mul vl]
> -	st1b	z0.b, p3, [dstin, #3, mul vl]
> -	st1b	z0.b, p4, [dstin, #4, mul vl]
> -	st1b	z0.b, p5, [dstin, #5, mul vl]
> -	st1b	z0.b, p6, [dstin, #6, mul vl]
> -	st1b	z0.b, p7, [dstin, #7, mul vl]
> -	ret
> -	.endm
>  
> -ENTRY (MEMSET)
> +#undef BTI_C
> +#define BTI_C
>  
> +ENTRY (MEMSET)
>  	PTR_ARG (0)
>  	SIZE_ARG (2)
>  
> -	cbnz	count, 1f
> -	ret
> -1:	dup	z0.b, valw
>  	cntb	vector_length
> -	// shortcut for less than vector_length * 8
> -	// gives a free ptrue to p0.b for n >= vector_length
> -	shortcut_for_small_size L(vl_agnostic)
> -	// end of shortcut
> +	dup	z0.b, valw
> +	whilelo	p0.b, vector_length, count
> +	b.last	1f
> +	whilelo	p1.b, xzr, count
> +	st1b	z0.b, p1, [dstin, 0, mul vl]
> +	st1b	z0.b, p0, [dstin, 1, mul vl]
> +	ret
> +
> +	// count >= vector_length * 2
> +1:	cmp	count, vector_length, lsl 2
> +	add	dstend, dstin, count
> +	b.hi	1f
> +	st1b	z0.b, p0, [dstin, 0, mul vl]
> +	st1b	z0.b, p0, [dstin, 1, mul vl]
> +	st1b	z0.b, p0, [dstend, -2, mul vl]
> +	st1b	z0.b, p0, [dstend, -1, mul vl]
> +	ret
> +
> +	// count > vector_length * 4
> +1:	lsl	tmp1, vector_length, 3
> +	cmp	count, tmp1
> +	b.hi	L(vl_agnostic)
> +	st1b	z0.b, p0, [dstin, 0, mul vl]
> +	st1b	z0.b, p0, [dstin, 1, mul vl]
> +	st1b	z0.b, p0, [dstin, 2, mul vl]
> +	st1b	z0.b, p0, [dstin, 3, mul vl]
> +	st1b	z0.b, p0, [dstend, -4, mul vl]
> +	st1b	z0.b, p0, [dstend, -3, mul vl]
> +	st1b	z0.b, p0, [dstend, -2, mul vl]
> +	st1b	z0.b, p0, [dstend, -1, mul vl]
> +	ret
>  
> +	.p2align 4
>  L(vl_agnostic): // VL Agnostic
>  	mov	rest, count
>  	mov	dst, dstin

-- 


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=10359.611248eb.b81fa.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+%5BPATCH+v4+1%2F5%5D+AArch64%3A+Improve+A64FX+memset+for+small+sizes&verdict=C&c=1592a97e59d9c303d39a44720394bc7a00abe6e6

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Undelivered Mail Returned to Sender
       [not found] ` <9531c4c9-2354-4c87-4453-b492afec846f@redhat.com>
@ 2020-12-16  0:42   ` Zack Weinberg
  0 siblings, 0 replies; 27+ messages in thread
From: Zack Weinberg @ 2020-12-16  0:42 UTC (permalink / raw)
  To: Carlos O'Donell, GNU C Library

 I have no idea why my mail glitched like that.  Sorry for the inconvenience.

On Tue, Dec 15, 2020 at 5:42 PM Carlos O'Donell <carlos@redhat.com> wrote:
>On 12/15/20 4:04 PM, Zack Weinberg wrote:
>> On Tue, Dec 15, 2020 at 3:46 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>>> On 12/15/20 8:05 AM, Zack Weinberg wrote:
>>>> When direct execution of a program fails with ENOEXEC, do not attempt
>>>> to run that program as if it were a shell script.
>>>
>>> A less-intrusive approach would be for execlp etc.'s fallback to look at the
>>> first 1024 bytes (or whatever) of the file and fail with ENOEXEC if it finds
>>> a NUL byte, before trying to exec /bin/sh on the file.
>>
>> That's a clever idea for preserving compatibility, but to do it we
>> would have to open and read the file, which could easily cause
>> problems due to e.g. lack of free file descriptor space.  If we can't
>> remove this code altogether I'm not sure it's worth changing anything
>> in libc.
>>
>> POSIX recommends that the *shell* implement a similar heuristic, and
>> it appears bash already does.
>
>What shell were you using that didn't implement this?

dash doesn't, and neither does zsh --

$ bash /bin/ls; echo $?
/bin/ls: /bin/ls: cannot execute binary file
126

$ dash /bin/ls; echo $?
/bin/ls: 1: Syntax error: ")" unexpected
2

$ zsh /bin/ls; echo $?
/bin/ls:1: parse error near ')'

Also, it's pretty easy to subvert bash's heuristic:

$ dd if=/dev/urandom count=1 | tr -d '\0' > test.x
$ bash test.x
test.x: line 4: syntax error near unexpected token
`$'\333\313\353D\341\252\341N\330\313\342\a\202g\027\225\276kE!\332\315D\226/M\2669\222''

zw

^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, other threads:[~2021-08-11  0:54 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-10 21:15 Undelivered Mail Returned to Sender MAILER-DAEMON
  -- strict thread matches above, loose matches on Subject: below --
2021-08-11  0:54 MAILER-DAEMON
2021-08-10 22:34 MAILER-DAEMON
2021-08-10 22:19 MAILER-DAEMON
2021-08-10 21:09 MAILER-DAEMON
2021-08-10 21:03 MAILER-DAEMON
2021-08-10 20:11 MAILER-DAEMON
2021-08-10 19:50 MAILER-DAEMON
2021-08-10 18:12 MAILER-DAEMON
2021-08-10 18:04 MAILER-DAEMON
2021-08-10 18:03 MAILER-DAEMON
2021-08-10 17:48 MAILER-DAEMON
2021-08-10 17:41 MAILER-DAEMON
2021-08-10 17:39 MAILER-DAEMON
2021-08-10 15:42 MAILER-DAEMON
2021-08-10 14:39 MAILER-DAEMON
2021-08-10 13:49 MAILER-DAEMON
2021-08-10 13:34 MAILER-DAEMON
2021-08-10 13:21 MAILER-DAEMON
2021-08-10 13:02 MAILER-DAEMON
2021-08-10 11:20 MAILER-DAEMON
2021-08-10  9:45 MAILER-DAEMON
2021-08-10  9:44 MAILER-DAEMON
2021-08-10  9:41 MAILER-DAEMON
2021-08-10  9:39 MAILER-DAEMON
2021-08-10  9:37 MAILER-DAEMON
     [not found] <4CwXgY5nCWzFr7@mailbackend.panix.com>
     [not found] ` <9531c4c9-2354-4c87-4453-b492afec846f@redhat.com>
2020-12-16  0:42   ` Zack Weinberg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).