Re: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER

2020-03-31 Thread Claudiu Zissulescu Ianculescu 
Pushed.

Thank you,
Claudiu

On Sun, Mar 29, 2020 at 2:05 AM Vineet Gupta via Gcc-patches
 wrote:
>
> Enable big-endian suffixed dynamic linker per glibc multi-abi support.
>
> And to avoid a future churn and version pairingi hassles, also allow
> arc700 although glibc for ARC currently doesn't support it.
>
> gcc/
> -xx-xx  Vineet Gupta 
> +
> +   * config/arc/linux.h: GLIBC_DYNAMIC_LINKER support BE/arc700
>
> Signed-off-by: Vineet Gupta 
> ---
>  gcc/ChangeLog  | 4 
>  gcc/config/arc/linux.h | 2 +-
>  2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 86ad683a6cb0..c26a748fd51b 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,7 @@
> +2020-03-28  Vineet Gupta 
> +
> +   * config/arc/linux.h: GLIBC_DYNAMIC_LINKER support BE/arc700
> +
>  2020-03-28  Jakub Jelinek  
>
> PR c/93573
> diff --git a/gcc/config/arc/linux.h b/gcc/config/arc/linux.h
> index 0b99da3fcdaf..1bbeccee7115 100644
> --- a/gcc/config/arc/linux.h
> +++ b/gcc/config/arc/linux.h
> @@ -29,7 +29,7 @@ along with GCC; see the file COPYING3.  If not see
>  }  \
>while (0)
>
> -#define GLIBC_DYNAMIC_LINKER   "/lib/ld-linux-arc.so.2"
> +#define GLIBC_DYNAMIC_LINKER   
> "/lib/ld-linux-arc%{mbig-endian:eb}%{mcpu=arc700:700}.so.2"
>  #define UCLIBC_DYNAMIC_LINKER  "/lib/ld-uClibc.so.0"
>
>  /* Note that the default is to link against dynamic libraries, if they are
> --
> 2.20.1
>

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V2 0/3] mm/debug: Add more arch page table helper tests

2020-03-31 Thread Gerald Schaefer 
On Tue, 24 Mar 2020 10:52:52 +0530
Anshuman Khandual  wrote:

> This series adds more arch page table helper tests. The new tests here are
> either related to core memory functions and advanced arch pgtable helpers.
> This also creates a documentation file enlisting all expected semantics as
> suggested by Mike Rapoport (https://lkml.org/lkml/2020/1/30/40).
> 
> This series has been tested on arm64 and x86 platforms. There is just one
> expected failure on arm64 that will be fixed when we enable THP migration.
> 
> [   21.741634] WARNING: CPU: 0 PID: 1 at mm/debug_vm_pgtable.c:782
> 
> which corresponds to
> 
> WARN_ON(!pmd_present(pmd_mknotpresent(pmd_mkhuge(pmd
> 
> There are many TRANSPARENT_HUGEPAGE and ARCH_HAS_TRANSPARENT_HUGEPAGE_PUD
> ifdefs scattered across the test. But consolidating all the fallback stubs
> is not very straight forward because ARCH_HAS_TRANSPARENT_HUGEPAGE_PUD is
> not explicitly dependent on ARCH_HAS_TRANSPARENT_HUGEPAGE.
> 
> This series has been build tested on many platforms including the ones that
> subscribe the test through ARCH_HAS_DEBUG_VM_PGTABLE.
> 

Hi Anshuman,

thanks for the update. There are a couple of issues on s390, some might
also affect other archs.

1) The pxd_huge_tests are using pxd_set/clear_huge, which defaults to
returning 0 if !CONFIG_HAVE_ARCH_HUGE_VMAP. As result, the checks for
!pxd_test/clear_huge in the pxd_huge_tests will always trigger the
warning. This should affect all archs w/o CONFIG_HAVE_ARCH_HUGE_VMAP.
Could be fixed like this:

@@ -923,8 +923,10 @@ void __init debug_vm_pgtable(void)
pmd_leaf_tests(pmd_aligned, prot);
pud_leaf_tests(pud_aligned, prot);
 
-   pmd_huge_tests(pmdp, pmd_aligned, prot);
-   pud_huge_tests(pudp, pud_aligned, prot);
+   if (IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP)) {
+   pmd_huge_tests(pmdp, pmd_aligned, prot);
+   pud_huge_tests(pudp, pud_aligned, prot);
+   }
 
pte_savedwrite_tests(pte_aligned, prot);
pmd_savedwrite_tests(pmd_aligned, prot);

BTW, please add some comments to the various #ifdef/#else stuff, especially
when the different parts are far away and/or nested.

2) The hugetlb_advanced_test will fail because it directly de-references
huge *ptep pointers instead of using huge_ptep_get() for this. We have
very different pagetable entry layout for pte and (large) pmd on s390,
and unfortunately the whole hugetlbfs code is using pte_t instead of pmd_t
like THP. For this reason, huge_ptep_get() was introduced, which will
return a "converted" pte, because directly reading from a *ptep (pointing
to a large pmd) will not return a proper pte. Only ARM has also an
implementation of huge_ptep_get(), so they could be affected, depending
on what exactly they need it for.

Could be fixed like this (the first de-reference is a bit special,
because at that point *ptep does not really point to a large (pmd) entry
yet, it is initially an invalid pte entry, which breaks our huge_ptep_get()
conversion logic. I also added PMD_MASK alignment for RANDOM_ORVALUE,
because we do have some special bits there in our large pmds. It seems
to also work w/o that alignment, but it feels a bit wrong):

@@ -731,26 +731,26 @@ static void __init hugetlb_advanced_test
  unsigned long vaddr, pgprot_t prot)
 {
struct page *page = pfn_to_page(pfn);
-   pte_t pte = READ_ONCE(*ptep);
+   pte_t pte;

-   pte = __pte(pte_val(pte) | RANDOM_ORVALUE);
+   pte = pte_mkhuge(mk_pte_phys(RANDOM_ORVALUE & PMD_MASK, prot));
set_huge_pte_at(mm, vaddr, ptep, pte);
barrier();
WARN_ON(!pte_same(pte, huge_ptep_get(ptep)));
huge_pte_clear(mm, vaddr, ptep, PMD_SIZE);
-   pte = READ_ONCE(*ptep);
+   pte = huge_ptep_get(ptep);
WARN_ON(!huge_pte_none(pte));
 
pte = mk_huge_pte(page, prot);
set_huge_pte_at(mm, vaddr, ptep, pte);
huge_ptep_set_wrprotect(mm, vaddr, ptep);
-   pte = READ_ONCE(*ptep);
+   pte = huge_ptep_get(ptep);
WARN_ON(huge_pte_write(pte));
 
pte = mk_huge_pte(page, prot);
set_huge_pte_at(mm, vaddr, ptep, pte);
huge_ptep_get_and_clear(mm, vaddr, ptep);
-   pte = READ_ONCE(*ptep);
+   pte = huge_ptep_get(ptep);
WARN_ON(!huge_pte_none(pte));
 
pte = mk_huge_pte(page, prot);
@@ -759,7 +759,7 @@ static void __init hugetlb_advanced_test
pte = huge_pte_mkwrite(pte);
pte = huge_pte_mkdirty(pte);
huge_ptep_set_access_flags(vma, vaddr, ptep, pte, 1);
-   pte = READ_ONCE(*ptep);
+   pte = huge_ptep_get(ptep);
WARN_ON(!(huge_pte_write(pte) && huge_pte_dirty(pte)));
 }
 #else

3) The pmd_protnone_tests() has an issue, because it passes a pmd to
pmd_protnone() which has not been marked as large. We check for large
pmd in the s390 implementation of pmd_protnone(), and will fail if a
pmd is not large. We had similar issues before, in other helpers, where
I

RE: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER

2020-03-31 Thread Alexey Brodkin 
Hi Claus,

> -Original Message-
> From: linux-snps-arc  On Behalf 
> Of Claudiu Zissulescu
> Ianculescu
> Sent: Tuesday, March 31, 2020 1:07 PM
> To: Vineet Gupta 
> Cc: linux-snps-arc@lists.infradead.org; gcc-patc...@gcc.gnu.org; Claudiu 
> Zissulescu
> 
> Subject: Re: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER
> 
> Pushed.

Is this one eligible for being back-ported to older GCCs?
At least GCC 9.x would be really good.

-Alexey
 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER

2020-03-31 Thread Vineet Gupta 
Well its a hard requirement considering glibc is still using gcc-9 !

Thx,
-Vineet

On 3/31/20 9:26 AM, Alexey Brodkin wrote:
> Hi Claus,
>
>> -Original Message-
>> From: linux-snps-arc  On Behalf 
>> Of Claudiu Zissulescu
>> Ianculescu
>> Sent: Tuesday, March 31, 2020 1:07 PM
>> To: Vineet Gupta 
>> Cc: linux-snps-arc@lists.infradead.org; gcc-patc...@gcc.gnu.org; Claudiu 
>> Zissulescu
>> 
>> Subject: Re: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER
>>
>> Pushed.
> Is this one eligible for being back-ported to older GCCs?
> At least GCC 9.x would be really good.
>
> -Alexey
>  

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] provide y2038 safe socket constants

2020-03-31 Thread Vineet Gupta 
ping !

On 3/28/20 9:16 PM, Vineet Gupta wrote:
> These will be used by upcoming RV32 and ARC ports and any future ports
> 
> Signed-off-by: Vineet Gupta 
> ---
>  sysdeps/unix/sysv/linux/bits/socket-constants.h | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/sysdeps/unix/sysv/linux/bits/socket-constants.h 
> b/sysdeps/unix/sysv/linux/bits/socket-constants.h
> index 9dcc19cd5380..8a48ae7d0ca2 100644
> --- a/sysdeps/unix/sysv/linux/bits/socket-constants.h
> +++ b/sysdeps/unix/sysv/linux/bits/socket-constants.h
> @@ -20,6 +20,8 @@
>  # error "Never include  directly; use 
>  instead."
>  #endif
>  
> +#include 
> +
>  #define SOL_SOCKET 1
>  #define SO_ACCEPTCONN 30
>  #define SO_BROADCAST 6
> @@ -30,9 +32,17 @@
>  #define SO_OOBINLINE 10
>  #define SO_RCVBUF 8
>  #define SO_RCVLOWAT 18
> -#define SO_RCVTIMEO 20
> +#if __TIMESIZE == 64 && __WORDSIZE == 32
> +# define SO_RCVTIMEO 66
> +#else
> +# define SO_RCVTIMEO 20
> +#endif
>  #define SO_REUSEADDR 2
>  #define SO_SNDBUF 7
>  #define SO_SNDLOWAT 19
> -#define SO_SNDTIMEO 21
> +#if __TIMESIZE == 64 && __WORDSIZE == 32
> +# define SO_SNDTIMEO 67
> +#else
> +# define SO_SNDTIMEO 21
> +#endif
>  #define SO_TYPE 3
> 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] provide y2038 safe socket constants

2020-03-31 Thread Florian Weimer 
* Vineet Gupta via Libc-alpha:

> These will be used by upcoming RV32 and ARC ports and any future ports
>
> Signed-off-by: Vineet Gupta 
> ---
>  sysdeps/unix/sysv/linux/bits/socket-constants.h | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/sysdeps/unix/sysv/linux/bits/socket-constants.h 
> b/sysdeps/unix/sysv/linux/bits/socket-constants.h
> index 9dcc19cd5380..8a48ae7d0ca2 100644
> --- a/sysdeps/unix/sysv/linux/bits/socket-constants.h
> +++ b/sysdeps/unix/sysv/linux/bits/socket-constants.h

What about the parallel changes to the sysdeps overrides?  I would
expect changes for hppa, mips, powerpc.  (Not sure about the alpha
situation.)

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] provide y2038 safe socket constants

2020-03-31 Thread Vineet Gupta 
On 3/31/20 12:34 PM, Florian Weimer wrote:
> What about the parallel changes to the sysdeps overrides? I would> expect 
> changes for hppa, mips, powerpc.  (Not sure about the alpha
> situation.)

This patch fixes the existing/future asm-generic ABI enabled arches and the ones
you refer to are not. So IMHO that would be a separate patch if at all.

But if they do need fixing, I'm all up for it - except that I'm not sure if 
their
ABI is changing too. Which brings us (me) to a fundamental question, how are 
those
arches going to be made y2038 safe (me goes and reads the big wiki page)

Thx,
-Vineet


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] provide y2038 safe socket constants

2020-03-31 Thread Florian Weimer 
* Vineet Gupta:

> On 3/31/20 12:34 PM, Florian Weimer wrote:
>> What about the parallel changes to the sysdeps overrides? I would> expect 
>> changes for hppa, mips, powerpc.  (Not sure about the alpha
>> situation.)
>
> This patch fixes the existing/future asm-generic ABI enabled arches
> and the ones you refer to are not. So IMHO that would be a separate
> patch if at all.

Ahh, I think the commit message could make this clearer (although it
it's somewhat implied).  The commit message also lacks a period at the
end.

But is the conditional correct for x32?  It has to be keep using the
old macro definitions.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] provide y2038 safe socket constants

2020-03-31 Thread Vineet Gupta 
+CC libc-alpha which got lost in the thread.

On 3/31/20 1:18 PM, Florian Weimer wrote:
> * Vineet Gupta:
> 
>> On 3/31/20 12:34 PM, Florian Weimer wrote:
>>> What about the parallel changes to the sysdeps overrides? I would> expect 
>>> changes for hppa, mips, powerpc.  (Not sure about the alpha
>>> situation.)
>>
>> This patch fixes the existing/future asm-generic ABI enabled arches
>> and the ones you refer to are not. So IMHO that would be a separate
>> patch if at all.
> 
> Ahh, I think the commit message could make this clearer (although it
> it's somewhat implied). 

Sure I can make it more explicit.

> The commit message also lacks a period at the
> end.

Will fix for v2.

> But is the conditional correct for x32?  It has to be keep using the
> old macro definitions.

I was not sure as some of the other patches in area don't seem to do that. 
Hence I
CC'ed Stephan who had earlier commented on x32.


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] provide y2038 safe socket constants

2020-03-31 Thread Joseph Myers 
On Tue, 31 Mar 2020, Florian Weimer wrote:

> What about the parallel changes to the sysdeps overrides?  I would
> expect changes for hppa, mips, powerpc.  (Not sure about the alpha
> situation.)

This fix is only about the case where the *default* ABI in glibc requires 
these different values.

The header will need further changes (to use a conditional not based on 
__TIMESIZE) when _TIME_BITS=64 is supported on platforms that currently 
have 32-bit time_t.  That's the point at which changes for other 
architectures are needed - once we have an appropriate conditional for 
"the current compilation uses 64-bit time but kernel long is 32-bit" (or 
something like that).

I'm concerned the present patch is wrong for x32, however; that has 
__TIMESIZE == 64 && __WORDSIZE == 32 but should use the old values; the 
patch should be using __SYSCALL_WORDSIZE when available in place of 
__WORDSIZE.

-- 
Joseph S. Myers
jos...@codesourcery.com

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] provide y2038 safe socket constants

2020-03-31 Thread Vineet Gupta 
On 3/31/20 1:45 PM, Joseph Myers wrote:
> I'm concerned the present patch is wrong for x32, however; that has 
> __TIMESIZE == 64 && __WORDSIZE == 32 but should use the old values; the 
> patch should be using __SYSCALL_WORDSIZE when available in place of 
> __WORDSIZE.

Something like below ?

-#if __TIMESIZE == 64 && __WORDSIZE == 32

+#if TIMESIZE == 64 && (__WORDSIZE == 32 \
 && (!defined __SYSCALL_WORDSIZE || __SYSCALL_WORDSIZE == 32))

Also is it ok to littler the code (multiple times, this patch and else where) 
with
this or should we define a new __32BIT_ARCH_NOT_X32 or some such ?
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Big Endian support as multi-ABI (was Re: [PATCH v4 02/15] ARC: ABI Implementation)

2020-03-31 Thread Vineet Gupta 
On 3/26/20 11:48 AM, Joseph Myers wrote:
> Yes, if you want to support BE then it should be documented as supported, 
> it should have its own dynamic linker name (with consequent GCC change 
> required to use that name) and it should have its own build in 
> build-many-glibcs.py.

So I booted the reworked BE support as proper multi-ABI (so abi variants in
sysdeps makefile, configure and ld versions in arc sysdeps ldconfig.h and
shlib-versions

However I'm a bit unsure about other elaborations needed per your comments in 
[1].
It seems they make sense when disparate ABIs can co-exit. Quoting some lines 
from [1]

| "support simultaneous presence of
| libraries for two different ABIs on a single system (hard-float and
| soft-float ABIs)..."

| "In cases where libraries for multiple ABIs may be present at once, there
| should be flags defined in sysdeps/generic/ldconfig.h..."

But a BE system can't possibly be mixed with a LE, its not really a multilib 
case
IMHO and a totally separate software stack build. So things like rewriting ldd 
to
be able to detect either ABI don't really apply as we need a seperate ldd built
for LE/BE for it to be even exec'ed by Linux kernel.

Going back to the list of needed parts in [1]

> sysdeps ldconfig.h file defining SYSDEP_KNOWN_INTERPRETER_NAMES with all
> the supported dynamic linker names.

Added entries for ARC LE/BE

> flags defined in sysdeps/generic/ldconfig.h to allow such libraries to be
> distinguished in ld.so.cache.

I don't see any other BE entry.

> elf/cache.c should include support for printing a corresponding description
> for those flags.

Ditto.

> sysdeps readelflib.c file that includes code to identify the flags to
> associate with a given shared library.

> sysdeps dl-cache.h defining _dl_cache_check_flags and (given that you
> use directories other than plain lib) add_system_dir.

They seem to be used for 32/64 support and/or different soft/hard float
implementation, but not for BE

> ldd_rewrite_script setting in a sysdeps configure.ac file, pointing to a
> sed script that edits ldd so that ldd installed by glibc build for any ABI
> is able to work properly for binaries of any other ABI that can execute on
> that system.

I don't see the point as it will never need to run.

Again the intent is not to reduce work for myself :-) but to do things right.

Thx,
-Vineet

[1] https://sourceware.org/legacy-ml/libc-alpha/2018-01/msg8.html
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] provide y2038 safe socket constants

2020-03-31 Thread Joseph Myers 
On Tue, 31 Mar 2020, Vineet Gupta via Libc-alpha wrote:

> On 3/31/20 1:45 PM, Joseph Myers wrote:
> > I'm concerned the present patch is wrong for x32, however; that has 
> > __TIMESIZE == 64 && __WORDSIZE == 32 but should use the old values; the 
> > patch should be using __SYSCALL_WORDSIZE when available in place of 
> > __WORDSIZE.
> 
> Something like below ?
> 
> -#if __TIMESIZE == 64 && __WORDSIZE == 32
> 
> +#if TIMESIZE == 64 && (__WORDSIZE == 32 \
>  && (!defined __SYSCALL_WORDSIZE || __SYSCALL_WORDSIZE == 32))

Yes, that sort of thing.

-- 
Joseph S. Myers
jos...@codesourcery.com

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: Big Endian support as multi-ABI (was Re: [PATCH v4 02/15] ARC: ABI Implementation)

2020-03-31 Thread Joseph Myers 
On Tue, 31 Mar 2020, Vineet Gupta via Libc-alpha wrote:

> But a BE system can't possibly be mixed with a LE, its not really a 
> multilib case

Indeed.  The Linux kernel does not support running BE processes on an LE 
kernel or vice versa, even when the underlying architecture does support 
runtime changes of endianness.  So all the pieces that are relevant for 
32-bit / 64-bit coexistence like that are irrelevant (but each ABI should 
still have a unique dynamic linker name).

-- 
Joseph S. Myers
jos...@codesourcery.com

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v2] provide y2038 safe socket constants for default/asm-generic ABI

2020-03-31 Thread Vineet Gupta 
These will be used by upcoming RV32 and ARC ports and any future ports.

Signed-off-by: Alistair Francis 
Signed-off-by: Vineet Gupta 
---
This is a straight copy of code originally written by Alistair, hence
adding his SOB as well
---
 sysdeps/unix/sysv/linux/bits/socket-constants.h | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/sysdeps/unix/sysv/linux/bits/socket-constants.h 
b/sysdeps/unix/sysv/linux/bits/socket-constants.h
index 9dcc19cd5380..d02e1cbc7cf1 100644
--- a/sysdeps/unix/sysv/linux/bits/socket-constants.h
+++ b/sysdeps/unix/sysv/linux/bits/socket-constants.h
@@ -20,6 +20,8 @@
 # error "Never include  directly; use  
instead."
 #endif
 
+#include 
+
 #define SOL_SOCKET 1
 #define SO_ACCEPTCONN 30
 #define SO_BROADCAST 6
@@ -30,9 +32,19 @@
 #define SO_OOBINLINE 10
 #define SO_RCVBUF 8
 #define SO_RCVLOWAT 18
-#define SO_RCVTIMEO 20
+#if (__TIMESIZE == 64 && __WORDSIZE == 32 \
+ && (!defined __SYSCALL_WORDSIZE || __SYSCALL_WORDSIZE == 32))
+# define SO_RCVTIMEO 66
+#else
+# define SO_RCVTIMEO 20
+#endif
 #define SO_REUSEADDR 2
 #define SO_SNDBUF 7
 #define SO_SNDLOWAT 19
-#define SO_SNDTIMEO 21
+#if (__TIMESIZE == 64 && __WORDSIZE == 32 \
+ && (!defined __SYSCALL_WORDSIZE || __SYSCALL_WORDSIZE == 32))
+# define SO_SNDTIMEO 67
+#else
+# define SO_SNDTIMEO 21
+#endif
 #define SO_TYPE 3
-- 
2.20.1


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: Big Endian support as multi-ABI (was Re: [PATCH v4 02/15] ARC: ABI Implementation)

2020-03-31 Thread Vineet Gupta 
On 3/31/20 2:27 PM, Joseph Myers wrote:
> On Tue, 31 Mar 2020, Vineet Gupta via Libc-alpha wrote:
> 
>> But a BE system can't possibly be mixed with a LE, its not really a 
>> multilib case
>
> Indeed.  The Linux kernel does not support running BE processes on an LE 
> kernel or vice versa, even when the underlying architecture does support 
> runtime changes of endianness.  So all the pieces that are relevant for 
> 32-bit / 64-bit coexistence like that are irrelevant (but each ABI should 
> still have a unique dynamic linker name).

Thx for confirming.

-Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v3] Make any 32-bit time based syscalls unavailable for TIMESIZE==64

2020-03-31 Thread Vineet Gupta 
From: Vineet Gupta via Libc-alpha 

An older asm-generic syscall ABI may have kernel provide 32-bit
time syscalls, so undef them to not mix 32/64 in 64-bit time regime.

Signed-off-by: Vineet Gupta 
---
Changes since v2
  - Made x32 safe

Changes since v1
  - don't redirect these to 64-bit variants
---
 sysdeps/unix/sysv/linux/generic/sysdep.h | 24 
 1 file changed, 24 insertions(+)

diff --git a/sysdeps/unix/sysv/linux/generic/sysdep.h 
b/sysdeps/unix/sysv/linux/generic/sysdep.h
index 40b4b955ca1b..b83e17e1c9d1 100644
--- a/sysdeps/unix/sysv/linux/generic/sysdep.h
+++ b/sysdeps/unix/sysv/linux/generic/sysdep.h
@@ -17,6 +17,7 @@
.  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,3 +26,26 @@
 #ifdef __NR_llseek
 # define __NR__llseek __NR_llseek
 #endif
+
+#if (__TIMESIZE == 64 && __WORDSIZE == 32 \
+ && (!defined __SYSCALL_WORDSIZE || __SYSCALL_WORDSIZE == 32))
+
+/* Don't provide 32-bit time syscalls even if the kernel ABI provides
+   them (Older variants of asm-generic ABIs e.g. ARC).  */
+
+# undef __NR_futex
+# undef __NR_rt_sigtimedwait
+# undef __NR_ppoll
+# undef __NR_utimensat
+# undef __NR_pselect6
+# undef __NR_recvmmsg
+# undef __NR_semtimedop
+# undef __NR_mq_timedreceive
+# undef __NR_mq_timedsend
+# undef __NR_clock_getres
+# undef __NR_timerfd_settime
+# undef __NR_timerfd_gettime
+# undef __NR_sched_rr_get_interval
+# undef __NR_clock_adjtime
+
+#endif
-- 
2.20.1


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v4 13/15] ARC: Build Infrastructure

2020-03-31 Thread Vineet Gupta 
On 3/27/20 11:42 PM, Vineet Gupta via Libc-alpha wrote:
>>> +++ b/sysdeps/arc/Versions
>>> @@ -0,0 +1,6 @@
>>> +libc {
>>> +  GLIBC_2.32 {
>>> +__syscall_error;
>>
>> Why does __syscall_error need a public symbol version?  If it's used by a 
>> library other than libc, that means it needs to be exported at some symbol 
>> version - but it only needs a public version (as opposed to GLIBC_PRIVATE) 
>> if it might be used by user programs linked with glibc (if it's used in 
>> crt*.o, lib*_nonshared.a, or inline functions in installed headers, for 
>> example - or in libgcc.a, libstdc++.a, etc. (GCC static libraries)).
>
> We'll historically I've preferred an out-of-line errno setter in the syscall
> wrappers and those are used in libpthread et all as well but not expected to 
> be
> used by user programs. See my sysdeps.h

Ok so this will not be called directly from user programs, but indeed could end 
up
in  non shared libs and/or inline functions in headers, so I suppose this is 
fine ?

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v4 13/15] ARC: Build Infrastructure

2020-03-31 Thread Joseph Myers 
On Tue, 31 Mar 2020, Vineet Gupta via Libc-alpha wrote:

> On 3/27/20 11:42 PM, Vineet Gupta via Libc-alpha wrote:
> >>> +++ b/sysdeps/arc/Versions
> >>> @@ -0,0 +1,6 @@
> >>> +libc {
> >>> +  GLIBC_2.32 {
> >>> +__syscall_error;
> >>
> >> Why does __syscall_error need a public symbol version?  If it's used by a 
> >> library other than libc, that means it needs to be exported at some symbol 
> >> version - but it only needs a public version (as opposed to GLIBC_PRIVATE) 
> >> if it might be used by user programs linked with glibc (if it's used in 
> >> crt*.o, lib*_nonshared.a, or inline functions in installed headers, for 
> >> example - or in libgcc.a, libstdc++.a, etc. (GCC static libraries)).
> >
> > We'll historically I've preferred an out-of-line errno setter in the syscall
> > wrappers and those are used in libpthread et all as well but not expected 
> > to be
> > used by user programs. See my sysdeps.h
> 
> Ok so this will not be called directly from user programs, but indeed 
> could end up in non shared libs and/or inline functions in headers, so I 
> suppose this is fine ?

What inline function or object in lib*_nonshared.a / crt*.o / GCC static 
library has a reference to this symbol?

If there's an inline function referring to this in an installed header, we 
can consider whether that inline function *should* be referring to it.  
Similarly if there's a reference in crt*.o / lib*_nonshared.a / GCC static 
libraries, we can consider if that reference *should* be there or if the 
function in question should actually be calling some function from libc.so 
that does the syscall there.

-- 
Joseph S. Myers
jos...@codesourcery.com

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

__syscall_error (was Re: [PATCH v4 13/15] ARC: Build Infrastructure)

2020-03-31 Thread Vineet Gupta 
On 3/31/20 3:48 PM, Joseph Myers wrote:
> On Tue, 31 Mar 2020, Vineet Gupta via Libc-alpha wrote:
> 
>> On 3/27/20 11:42 PM, Vineet Gupta via Libc-alpha wrote:
> +++ b/sysdeps/arc/Versions
> @@ -0,0 +1,6 @@
> +libc {
> +  GLIBC_2.32 {
> +__syscall_error;

 Why does __syscall_error need a public symbol version?  If it's used by a 
 library other than libc, that means it needs to be exported at some symbol 
 version - but it only needs a public version (as opposed to GLIBC_PRIVATE) 
 if it might be used by user programs linked with glibc (if it's used in 
 crt*.o, lib*_nonshared.a, or inline functions in installed headers, for 
 example - or in libgcc.a, libstdc++.a, etc. (GCC static libraries)).
>>>
>>> We'll historically I've preferred an out-of-line errno setter in the syscall
>>> wrappers and those are used in libpthread et all as well but not expected 
>>> to be
>>> used by user programs. See my sysdeps.h
>>
>> Ok so this will not be called directly from user programs, but indeed 
>> could end up in non shared libs and/or inline functions in headers, so I 
>> suppose this is fine ?
> 
> What inline function or object in lib*_nonshared.a / crt*.o / GCC static 
> library has a reference to this symbol?
> 
> If there's an inline function referring to this in an installed header, we 
> can consider whether that inline function *should* be referring to it.  
> Similarly if there's a reference in crt*.o / lib*_nonshared.a / GCC static 
> libraries, we can consider if that reference *should* be there or if the 
> function in question should actually be calling some function from libc.so 
> that does the syscall there.

The assembler macros in syscall template for generating wrappers use
__syscall_error (sysdeps/unix/sysv/linux/arc/sysdep.h).

If public Version is removed, I get errors like below:

| arc-glibc-linux-gnu-gcc   -shared -static-libgcc -Wl,-O1  -Wl,-z,defs -Wl,
| -dynamic-linker=/lib/ld-linux-arc.so.2  -Wl,--version-script=/SCRATCH/vgupta
| /gnu/build/glibcs/arc-linux-gnu/glibc/librt.map -Wl,-soname=librt.so.1
|
| ...
| a - mq_setattr.o
| a - librt-cancellation.o
| /SCRATCH/vgupta/gnu/install/compilers/arc-linux-gnu/lib/gcc/arc-glibc-linux-
| gnu/10.0.1/../../../../arc-glibc-linux-gnu/bin/ld: /SCRATCH/vgupta/gnu/build
| /glibcs/arc-linux-gnu/glibc/rt/librt_pic.a(mq_setattr.os): in function
| `mq_setattr':
| /SCRATCH/vgupta/gnu/src/glibc/rt/../sysdeps/unix/syscall-template.S:80:
| undefined reference to `__syscall_error'

And this change goes back to initial port (in 2016) where openssh/libcrypt.so 
was
failing to link somewhat similarly.

Looking as RISCV code, they opencode __syscall_error for !IS_IN (libc) which I 
was
hoping to avoid.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER

2020-03-31 Thread Vineet Gupta 
FWIW this change needs a pairing glibc change so must NOT be included for 
upcoming
2020.x release which still has old version of glibc !

-Vineet


On 3/31/20 10:57 AM, Vineet Gupta wrote:
> Well its a hard requirement considering glibc is still using gcc-9 !
>
> Thx,
> -Vineet
>
> On 3/31/20 9:26 AM, Alexey Brodkin wrote:
>> Hi Claus,
>>
>>> -Original Message-
>>> From: linux-snps-arc  On Behalf 
>>> Of Claudiu Zissulescu
>>> Ianculescu
>>> Sent: Tuesday, March 31, 2020 1:07 PM
>>> To: Vineet Gupta 
>>> Cc: linux-snps-arc@lists.infradead.org; gcc-patc...@gcc.gnu.org; Claudiu 
>>> Zissulescu
>>> 
>>> Subject: Re: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER
>>>
>>> Pushed.
>> Is this one eligible for being back-ported to older GCCs?
>> At least GCC 9.x would be really good.
>>
>> -Alexey
>>  
> ___
> linux-snps-arc mailing list
> linux-snps-arc@lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dsnps-2Darc&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=c14YS-cH-kdhTOW89KozFhBtBJgs1zXscZojEZQ0THs&m=xnl4FBxLN70UDZIvD2NTxyfPAenrfQsdij0DBuPImCI&s=YnG2GxYtFIbUU0FesR19TV7fz0ILe8xncKLnRiqBhOc&e=
>  

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc