Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )

2020-03-25 Thread Helmut Grohne
Hi Vineet,

On Wed, Mar 25, 2020 at 05:25:58PM -0700, Vineet Gupta wrote:
> ARC glibc is still in works, but assuming that will happen in near future what
> other upstream prerequisites are needed. The obvious ones would be Linux 
> kernel,
> gcc, binutils: all 3 of which are supported for ARC. From a quick glance at 
> debian
> wiki pages, I presume *bootstrap is mostly done native, so needs qemu ? 
> (full/user
> emulation ? And does qemu need to be upstream too ?

Given that I ran into the glibc issue, I can tell that at least
rudimentary arc support support is already available in Debian unstable
for binutils, linux and gcc. (Otherwise, I would not have come as far as
glibc.) Once glibc is in place, work can proceed on the Debian side.
guile, libatomic-ops, libffi, libgpg-error and nspr ususally need a
little upstream support. dpkg, gmp, openssl, and perl usually need
Debian-specific changes. I'd recommend looking into libatomic-ops and
libffi early. The other packages are usually simple.

The aim of rebootstrap is to create a package set for essential +
build-essential using cross builds without using any qemu. Beyond that
point, you'd switch to native building. Unless real hardware is
available, you'd need qemu after the reboostrap phase. Whether you use
full or user emulation is your choice, but I guess that you can speed up
builds using user emulation, because it allows you to mix and match
binaries. When you upstream your qemu is also your choice.

Please get in touch with me once a suitable glibc is packaged for Debian
unstable or experimental. Please use debian-cr...@lists.debian.org or
irc.oftc.net #debian-bootstrap at that point. Alternatively, package a
glibc locally (like Arnd did).

Helmut

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


Re: [PATCH v4 07/15] ARC: hardware floating point support

2020-03-25 Thread Vineet Gupta
On 3/25/20 7:06 PM, Joseph Myers wrote:
> On Thu, 12 Mar 2020, Vineet Gupta via Libc-alpha wrote:
> 
>> diff --git a/sysdeps/arc/bits/fenv.h b/sysdeps/arc/bits/fenv.h
> 
> This is another example of one patch fixing up another.  You're using the 
> same ABI for both hard and soft float, so the first patch adding a 
> bits/fenv.h header should be using that ABI for fenv_t, rather than one 
> patch adding it with one ABI then a subsequent patch changing the 
> definition of that type.

Sorry about that. Indeed its a different mindset how we things do in glibc and 
I'm
learning that slowly. I've fixed soft-float so this file is not touched anymore
for hard-float.

>> diff --git a/sysdeps/arc/fpu/libm-test-ulps b/sysdeps/arc/fpu/libm-test-ulps
> 
> This will need updating for the recent changes to remove separate inline 
> function testing (so there should be no ifloat or idouble entries any 
> more).

OK. FWIW I'm counting on Alistair's 64-bit stuff (and his frequent rebases) to 
be
able to pick up latest upstream and then do the adjustments in ARC port. His
changes seem rock solid in my ARC testing and I was hoping they get merged 
sooner.


>> diff --git a/sysdeps/arc/tininess.h b/sysdeps/arc/tininess.h
>> new file mode 100644
>> index ..1db37790f881
>> --- /dev/null
>> +++ b/sysdeps/arc/tininess.h
>> @@ -0,0 +1 @@
>> +#define TININESS_AFTER_ROUNDING 1
> 
> In the soft-float patch you define _FP_TININESS_AFTER_ROUNDING to 0.  
> Formally it doesn't really matter since you aren't supporting exceptions 
> for soft-float anyway.  But typically I'd expect the definition of 
> _FP_TININESS_AFTER_ROUNDING, on architecture with support for both hard 
> and soft float, to match the architecture's rule for tininess detection 
> for hard-float.

OK I've updated soft-float.

Thx,
-Vineet

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


Re: [PATCH v4 06/15] ARC: math soft float support

2020-03-25 Thread Vineet Gupta
On 3/25/20 6:59 PM, Joseph Myers wrote:

>> +/* Soft-float doesnot support exceptions.  */
> Missing space, should be "does not".

Fixed.

Thx,
-Vineet

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


Re: [PATCH v4 04/15] ARC: Thread Local Storage support

2020-03-25 Thread Vineet Gupta
On 3/25/20 6:57 PM, Joseph Myers wrote:
> On Thu, 12 Mar 2020, Vineet Gupta via Libc-alpha wrote:
> 
>> +-- Derive offsets relative to the thread register.
>> +#define thread_offsetof(mem)(long)(offsetof(struct pthread, mem) - 
>> sizeof(struct pthread))
> 
> Missing spaces before '(' in calls to offsetof and sizeof.

Fixed.

> 
>> +TLS_TCB_SIZEsizeof(tcbhead_t)
>> +
>> +PTHREAD_TID offsetof(struct pthread, tid)
> 
> Likewise.
> 

Fixed.


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


Re: [PATCH v4 03/15] ARC: startup and dynamic linking code

2020-03-25 Thread Vineet Gupta
On 3/25/20 6:55 PM, Joseph Myers wrote:
> Do you mean DTPOFF?  Otherwise I'm not sure what DTSOFF is.

Fixed.

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


Re: [PATCH v4 02/15] ARC: ABI Implementation

2020-03-25 Thread Vineet Gupta
On 3/25/20 6:52 PM, Joseph Myers wrote:
> On Thu, 12 Mar 2020, Vineet Gupta via Libc-alpha wrote:
>> +/* ARC has selectable endianness.  */
>> +#ifdef __BIG_ENDIAN__
>> +# define __BYTE_ORDER __BIG_ENDIAN
>> +#else
>> +# define __BYTE_ORDER __LITTLE_ENDIAN
>> +#endif
> 
> Elsewhere you say the port is little-endian only.  In such cases we 
> generally have an error somewhere if you attempt to build glibc for the 
> other endianness, to avoid an other-endian configuration accidentally 
> building but not working and having a broken ABI.  For example, see what 
> Nios II does: sysdeps/nios2/bits/endianness.h handles both endiannesses, 
> but sysdeps/nios2/configure.ac produces an error for big-endian.

Hardware-wise, ARC can be configured to be LE or BE and software supports that
(cfr Linux or uClibc). The initial glibc port was only aiming LE but we ended up
with BE as well due to a customer engagement. And given much of ARC port is
currently generic (minimal asm), no real change was needed except enabling it in
this header. We do plan to officially support it so I guess we need some more
changes in Documentation / ABI listing etc.

> 
>> +/* PLT jump into resolver passes PC of PLTn, while _dl_fixup expects the
>> +   address of corresponding .rela.plt entry.  */
>> +
>> +#ifdef __A7__
>> +# define ARC_PLT_SIZE   12
>> +#else
>> +# define ARC_PLT_SIZE   16
>> +#endif
> 
> Is this some sort of ABI difference between two incompatible ABIs?  (The 
> ABI document you pointed to only seems to mention 12-byte PLT entries.)

Right, we've had 2 ARC ISA: current generation ARCv2 (basis for HS3x and HS4x
processors) and the older ARCompact (ARC700 cores which run Linux and still
supported e.g. in Mellanox NPS cores). From instruction set pov they are very
similar (although not binary compatible).

ARCompact PLT entry is 12 bytes
b18c:   ldr12,[pcl,0x00065584]  #8
b194:   j_s.d [r12] #2
b196:   mov_s r12,pcl   #2

ARCv2 prohibits--> mov_s with PCL and thus we have
b18c:   ldr12,[pcl,0x00065584]  #8
b194:   j.d   [r12] #4
b198:   mov   r12,pcl   #4

Again this is the only change needed for *testing* a ARCompact build as rest is
all taken care by how gcc is configured etc (and generates __A7__). This has 
also
been tested and boots Linux fine. We can add the necessary elaborations for
supporting it officially.

>> +#define reloc_index \
>> +({  \
>> +  unsigned long int plt0 = D_PTR (l, l_info[DT_PLTGOT]);\
>> +  unsigned long int pltn = reloc_arg;   \
>> +  /* Exclude PL0 and PLT1.  */  \
> 
> Should PL0 be PLT0 here?

Fixed.

>> +  unsigned long int idx = (pltn - plt0)/ARC_PLT_SIZE - 2;   \
> 
> Missing spaces around '/'.

Fixed.

> 
>> diff --git a/sysdeps/arc/gmp-mparam.h b/sysdeps/arc/gmp-mparam.h
>> new file mode 100644

[snip...]

>> +
>> +#define IEEE_DOUBLE_BIG_ENDIAN 0
> 
> Plenty of architectures that have, or support, little-endian floating 
> point do not have gmp-mparam.h at all.  IEEE_DOUBLE_BIG_ENDIAN is only 
> used to define union ieee_double_extract, which is nowhere used in glibc.  
> So I don't think you need this header at all 

Removed now.

(and it shows up the scope
> for a more general cleanup possible for other ports, I suspect only the 
> x32 and mips64 versions of this header, the ones that define 
> _LONG_LONG_LIMB for ILP32 configurations with 64-bit registers, are the 
> only non-generic ones that do anything useful - but you don't need to do 
> that cleanup).

Thx for taking a look.

-Vineet



___
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-25 Thread Anshuman Khandual



On 03/24/2020 10:52 AM, 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.

If folks can test these patches out on remaining ARCH_HAS_DEBUG_VM_PGTABLE
enabled platforms i.e s390, arc, powerpc (32 and 64), that will be really
appreciated. Thank you.

- Anshuman

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


Re: [PATCH V2 1/3] mm/debug: Add tests validating arch page table helpers for core features

2020-03-25 Thread Anshuman Khandual

On 03/24/2020 06:59 PM, Zi Yan wrote:
> On 24 Mar 2020, at 1:22, Anshuman Khandual wrote:
> 
>> This adds new tests validating arch page table helpers for these following
>> core memory features. These tests create and test specific mapping types at
>> various page table levels.
>>
>> 1. SPECIAL mapping
>> 2. PROTNONE mapping
>> 3. DEVMAP mapping
>> 4. SOFTDIRTY mapping
>> 5. SWAP mapping
>> 6. MIGRATION mapping
>> 7. HUGETLB mapping
>> 8. THP mapping
>>
>> Cc: Andrew Morton 
>> Cc: Mike Rapoport 
>> Cc: Vineet Gupta 
>> Cc: Catalin Marinas 
>> Cc: Will Deacon 
>> Cc: Benjamin Herrenschmidt 
>> Cc: Paul Mackerras 
>> Cc: Michael Ellerman 
>> Cc: Heiko Carstens 
>> Cc: Vasily Gorbik 
>> Cc: Christian Borntraeger 
>> Cc: Thomas Gleixner 
>> Cc: Ingo Molnar 
>> Cc: Borislav Petkov 
>> Cc: "H. Peter Anvin" 
>> Cc: Kirill A. Shutemov 
>> Cc: Paul Walmsley 
>> Cc: Palmer Dabbelt 
>> Cc: linux-snps-arc@lists.infradead.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linuxppc-...@lists.ozlabs.org
>> Cc: linux-s...@vger.kernel.org
>> Cc: linux-ri...@lists.infradead.org
>> Cc: x...@kernel.org
>> Cc: linux-a...@vger.kernel.org
>> Cc: linux-ker...@vger.kernel.org
>> Suggested-by: Catalin Marinas 
>> Signed-off-by: Anshuman Khandual 
>> ---
>>  mm/debug_vm_pgtable.c | 291 +-
>>  1 file changed, 290 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
>> index 98990a515268..15055a8f6478 100644
>> --- a/mm/debug_vm_pgtable.c
>> +++ b/mm/debug_vm_pgtable.c
>> @@ -289,6 +289,267 @@ static void __init pmd_populate_tests(struct mm_struct 
>> *mm, pmd_t *pmdp,
>>  WARN_ON(pmd_bad(pmd));
>>  }
>>
>> +static void __init pte_special_tests(unsigned long pfn, pgprot_t prot)
>> +{
>> +pte_t pte = pfn_pte(pfn, prot);
>> +
>> +if (!IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL))
>> +return;
>> +
>> +WARN_ON(!pte_special(pte_mkspecial(pte)));
>> +}
>> +
>> +static void __init pte_protnone_tests(unsigned long pfn, pgprot_t prot)
>> +{
>> +pte_t pte = pfn_pte(pfn, prot);
>> +
>> +if (!IS_ENABLED(CONFIG_NUMA_BALANCING))
>> +return;
>> +
>> +WARN_ON(!pte_protnone(pte));
>> +WARN_ON(!pte_present(pte));
>> +}
>> +
>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>> +static void __init pmd_protnone_tests(unsigned long pfn, pgprot_t prot)
>> +{
>> +pmd_t pmd = pfn_pmd(pfn, prot);
>> +
>> +if (!IS_ENABLED(CONFIG_NUMA_BALANCING))
>> +return;
>> +
>> +WARN_ON(!pmd_protnone(pmd));
>> +WARN_ON(!pmd_present(pmd));
>> +}
>> +#else
>> +static void __init pmd_protnone_tests(unsigned long pfn, pgprot_t prot) { }
>> +#endif
>> +
>> +#ifdef CONFIG_ARCH_HAS_PTE_DEVMAP
>> +static void __init pte_devmap_tests(unsigned long pfn, pgprot_t prot)
>> +{
>> +pte_t pte = pfn_pte(pfn, prot);
>> +
>> +WARN_ON(!pte_devmap(pte_mkdevmap(pte)));
>> +}
>> +
>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>> +static void __init pmd_devmap_tests(unsigned long pfn, pgprot_t prot)
>> +{
>> +pmd_t pmd = pfn_pmd(pfn, prot);
>> +
>> +WARN_ON(!pmd_devmap(pmd_mkdevmap(pmd)));
>> +}
>> +
>> +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
>> +static void __init pud_devmap_tests(unsigned long pfn, pgprot_t prot)
>> +{
>> +pud_t pud = pfn_pud(pfn, prot);
>> +
>> +WARN_ON(!pud_devmap(pud_mkdevmap(pud)));
>> +}
>> +#else
>> +static void __init pud_devmap_tests(unsigned long pfn, pgprot_t prot) { }
>> +#endif
>> +#else
>> +static void __init pmd_devmap_tests(unsigned long pfn, pgprot_t prot) { }
>> +static void __init pud_devmap_tests(unsigned long pfn, pgprot_t prot) { }
>> +#endif
>> +#else
>> +static void __init pte_devmap_tests(unsigned long pfn, pgprot_t prot) { }
>> +static void __init pmd_devmap_tests(unsigned long pfn, pgprot_t prot) { }
>> +static void __init pud_devmap_tests(unsigned long pfn, pgprot_t prot) { }
>> +#endif
>> +
>> +static void __init pte_soft_dirty_tests(unsigned long pfn, pgprot_t prot)
>> +{
>> +pte_t pte = pfn_pte(pfn, prot);
>> +
>> +if (!IS_ENABLED(CONFIG_HAVE_ARCH_SOFT_DIRTY))
>> +return;
>> +
>> +WARN_ON(!pte_soft_dirty(pte_mksoft_dirty(pte)));
>> +WARN_ON(pte_soft_dirty(pte_clear_soft_dirty(pte)));
>> +}
>> +
>> +static void __init pte_swap_soft_dirty_tests(unsigned long pfn, pgprot_t 
>> prot)
>> +{
>> +pte_t pte = pfn_pte(pfn, prot);
>> +
>> +if (!IS_ENABLED(CONFIG_HAVE_ARCH_SOFT_DIRTY))
>> +return;
>> +
>> +WARN_ON(!pte_swp_soft_dirty(pte_swp_mksoft_dirty(pte)));
>> +WARN_ON(pte_swp_soft_dirty(pte_swp_clear_soft_dirty(pte)));
>> +}
>> +
>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>> +static void __init pmd_soft_dirty_tests(unsigned long pfn, pgprot_t prot)
>> +{
>> +pmd_t pmd = pfn_pmd(pfn, prot);
>> +
>> +if (!IS_ENABLED(CONFIG_HAVE_ARCH_SOFT_DIRTY))
>> +return;
>> +
>> +WARN_ON(!pmd_soft_dirty(pmd_mksoft_dirty(pmd)));
>> +WARN_ON(pmd_soft_dirty(pmd_clear_soft_dirty(pmd)));
>> +}
>> +
>> +static void _

Re: [PATCH v4 07/15] ARC: hardware floating point support

2020-03-25 Thread Joseph Myers
On Thu, 12 Mar 2020, Vineet Gupta via Libc-alpha wrote:

> diff --git a/sysdeps/arc/bits/fenv.h b/sysdeps/arc/bits/fenv.h

This is another example of one patch fixing up another.  You're using the 
same ABI for both hard and soft float, so the first patch adding a 
bits/fenv.h header should be using that ABI for fenv_t, rather than one 
patch adding it with one ABI then a subsequent patch changing the 
definition of that type.

> diff --git a/sysdeps/arc/fpu/libm-test-ulps b/sysdeps/arc/fpu/libm-test-ulps

This will need updating for the recent changes to remove separate inline 
function testing (so there should be no ifloat or idouble entries any 
more).

> diff --git a/sysdeps/arc/tininess.h b/sysdeps/arc/tininess.h
> new file mode 100644
> index ..1db37790f881
> --- /dev/null
> +++ b/sysdeps/arc/tininess.h
> @@ -0,0 +1 @@
> +#define TININESS_AFTER_ROUNDING  1

In the soft-float patch you define _FP_TININESS_AFTER_ROUNDING to 0.  
Formally it doesn't really matter since you aren't supporting exceptions 
for soft-float anyway.  But typically I'd expect the definition of 
_FP_TININESS_AFTER_ROUNDING, on architecture with support for both hard 
and soft float, to match the architecture's rule for tininess detection 
for hard-float.

-- 
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 v4 06/15] ARC: math soft float support

2020-03-25 Thread Joseph Myers
On Thu, 12 Mar 2020, Vineet Gupta via Libc-alpha wrote:

> +/* Soft-float doesnot support exceptions.  */

Missing space, should be "does not".

-- 
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 v4 04/15] ARC: Thread Local Storage support

2020-03-25 Thread Joseph Myers
On Thu, 12 Mar 2020, Vineet Gupta via Libc-alpha wrote:

> +-- Derive offsets relative to the thread register.
> +#define thread_offsetof(mem) (long)(offsetof(struct pthread, mem) - 
> sizeof(struct pthread))

Missing spaces before '(' in calls to offsetof and sizeof.

> +TLS_TCB_SIZE sizeof(tcbhead_t)
> +
> +PTHREAD_TID  offsetof(struct pthread, tid)

Likewise.

-- 
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 v4 03/15] ARC: startup and dynamic linking code

2020-03-25 Thread Joseph Myers
On Thu, 12 Mar 2020, Vineet Gupta via Libc-alpha wrote:

> +case R_ARC_TLS_DTPOFF:
> +  if (sym != NULL)
> +/* Offset set by the linker in the GOT entry would be overwritten
> +   by dynamic loader instead of added to the symbol location.
> +   Other target have the same approach on DTSOFF relocs.  */

Do you mean DTPOFF?  Otherwise I'm not sure what DTSOFF is.

-- 
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 v4 01/15] ARC: add definitions to elf/elf.h

2020-03-25 Thread Vineet Gupta
On 3/25/20 6:37 PM, Joseph Myers wrote:
> This patch is OK (it can be committed without waiting for the rest of the 
> port to be ready).

Thx. Pushed !

-Vineet

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


Re: [PATCH v4 02/15] ARC: ABI Implementation

2020-03-25 Thread Joseph Myers
On Thu, 12 Mar 2020, Vineet Gupta via Libc-alpha wrote:

> diff --git a/sysdeps/arc/bits/endianness.h b/sysdeps/arc/bits/endianness.h
> new file mode 100644
> index ..8f17ca84b485
> --- /dev/null
> +++ b/sysdeps/arc/bits/endianness.h
> @@ -0,0 +1,15 @@
> +#ifndef _BITS_ENDIANNESS_H
> +#define _BITS_ENDIANNESS_H 1
> +
> +#ifndef _BITS_ENDIAN_H
> +# error "Never use  directly; include  instead."
> +#endif
> +
> +/* ARC has selectable endianness.  */
> +#ifdef __BIG_ENDIAN__
> +# define __BYTE_ORDER __BIG_ENDIAN
> +#else
> +# define __BYTE_ORDER __LITTLE_ENDIAN
> +#endif

Elsewhere you say the port is little-endian only.  In such cases we 
generally have an error somewhere if you attempt to build glibc for the 
other endianness, to avoid an other-endian configuration accidentally 
building but not working and having a broken ABI.  For example, see what 
Nios II does: sysdeps/nios2/bits/endianness.h handles both endiannesses, 
but sysdeps/nios2/configure.ac produces an error for big-endian.

> +/* PLT jump into resolver passes PC of PLTn, while _dl_fixup expects the
> +   address of corresponding .rela.plt entry.  */
> +
> +#ifdef __A7__
> +# define ARC_PLT_SIZE12
> +#else
> +# define ARC_PLT_SIZE16
> +#endif

Is this some sort of ABI difference between two incompatible ABIs?  (The 
ABI document you pointed to only seems to mention 12-byte PLT entries.)

> +#define reloc_index  \
> +({   \
> +  unsigned long int plt0 = D_PTR (l, l_info[DT_PLTGOT]); \
> +  unsigned long int pltn = reloc_arg;\
> +  /* Exclude PL0 and PLT1.  */   \

Should PL0 be PLT0 here?

> +  unsigned long int idx = (pltn - plt0)/ARC_PLT_SIZE - 2;\

Missing spaces around '/'.

> diff --git a/sysdeps/arc/gmp-mparam.h b/sysdeps/arc/gmp-mparam.h
> new file mode 100644
> index ..5580551483c8
> --- /dev/null
> +++ b/sysdeps/arc/gmp-mparam.h
> @@ -0,0 +1,23 @@
> +/* gmp-mparam.h -- Compiler/machine parameter header file.
> +
> +Copyright (C) 2017-2020 Free Software Foundation, Inc.
> +
> +This file is part of the GNU MP Library.
> +
> +The GNU MP 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 MP 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 MP Library; see the file COPYING.LIB.  If not, see
> +.  */
> +
> +#include 
> +
> +#define IEEE_DOUBLE_BIG_ENDIAN 0

Plenty of architectures that have, or support, little-endian floating 
point do not have gmp-mparam.h at all.  IEEE_DOUBLE_BIG_ENDIAN is only 
used to define union ieee_double_extract, which is nowhere used in glibc.  
So I don't think you need this header at all (and it shows up the scope 
for a more general cleanup possible for other ports, I suspect only the 
x32 and mips64 versions of this header, the ones that define 
_LONG_LONG_LIMB for ILP32 configurations with 64-bit registers, are the 
only non-generic ones that do anything useful - but you don't need to do 
that cleanup).

-- 
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 v4 01/15] ARC: add definitions to elf/elf.h

2020-03-25 Thread Joseph Myers
This patch is OK (it can be committed without waiting for the rest of the 
port to be ready).

-- 
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


ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )

2020-03-25 Thread Vineet Gupta
Hi Helmut,

On 2/20/20 8:27 AM, Helmut Grohne wrote:
> 
> Since I saw arc in the subject, I also threw arc at rebootstrap. Turns
> out that glibc 2.30 does not yet cover arc and using unpackaged versions
> of glibc is non-trivial for rebootstrap, so I cannot do much about that.
> Once arc support is in a released version of glibc, I'd be happy to be
> pinged about it.

ARC glibc is still in works, but assuming that will happen in near future what
other upstream prerequisites are needed. The obvious ones would be Linux kernel,
gcc, binutils: all 3 of which are supported for ARC. From a quick glance at 
debian
wiki pages, I presume *bootstrap is mostly done native, so needs qemu ? 
(full/user
emulation ? And does qemu need to be upstream too ?

Thx,
-Vineet


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