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

[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

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

[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

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

[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 v4 02/15] ARC: ABI Implementation

[Vineet Gupta]

On 3/27/20 4:35 PM, Joseph Myers wrote:
> On Fri, 27 Mar 2020, Vineet Gupta via Libc-alpha wrote:
> 
>> I added bits in sysdeps/arc/configure.ac and corresponding conditional in
>> shlib-version. But I have to ask (embarrassingly). how to I regenerate
>> sysdeps/arc/configure.  I tried all possibe autoconf cmds with toggles (both 
>> at
>> top and in sysdeps/arc) and even reran configure in build tree with
>> --enable-maintainer-mode

> autoconf sysdeps/arc/configure.ac > sysdeps/arc/configure

Much thanks.
___
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

[Joseph Myers]

On Fri, 27 Mar 2020, Vineet Gupta via Libc-alpha wrote:

> I added bits in sysdeps/arc/configure.ac and corresponding conditional in
> shlib-version. But I have to ask (embarrassingly). how to I regenerate
> sysdeps/arc/configure.  I tried all possibe autoconf cmds with toggles (both 
> at
> top and in sysdeps/arc) and even reran configure in build tree with
> --enable-maintainer-mode

autoconf sysdeps/arc/configure.ac > sysdeps/arc/configure

-- 
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 02/15] ARC: ABI Implementation

[Vineet Gupta]

On 3/26/20 11:48 AM, Joseph Myers wrote:
> On Wed, 25 Mar 2020, Vineet Gupta via Libc-alpha wrote:
> 
>> 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.
> 
> 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.

I added bits in sysdeps/arc/configure.ac and corresponding conditional in
shlib-version. But I have to ask (embarrassingly). how to I regenerate
sysdeps/arc/configure.  I tried all possibe autoconf cmds with toggles (both at
top and in sysdeps/arc) and even reran configure in build tree with
--enable-maintainer-mode


>> 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).
> 
> If they're not binary compatible (so you can't have a binary that works on 
> both) that indicates they should also be considered separate ABIs (so you 
> have four dynamic linker names, each with corresponding build in 
> build-many-glibcs.py, plus any other variants that are relevant to build 
> in build-many-glibcs.py without being different ABIs, such as hard/soft 
> float).

I'll drop ARC700 support for now and we can add it later if need be. I suppose
there are no other ABI/versioning/compat complications in such an approach.


___
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

[Vineet Gupta]

On 3/26/20 11:48 AM, Joseph Myers wrote:
> On Wed, 25 Mar 2020, Vineet Gupta via Libc-alpha wrote:
> 
>> 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.
> 
> 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.

OK.

>> 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).
> 
> If they're not binary compatible (so you can't have a binary that works on 
> both) that indicates they should also be considered separate ABIs (so you 
> have four dynamic linker names, each with corresponding build in 
> build-many-glibcs.py, plus any other variants that are relevant to build 
> in build-many-glibcs.py without being different ABIs, such as hard/soft 
> float).

OK.


___
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

[Joseph Myers]

On Wed, 25 Mar 2020, Vineet Gupta via Libc-alpha wrote:

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

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.

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

If they're not binary compatible (so you can't have a binary that works on 
both) that indicates they should also be considered separate ABIs (so you 
have four dynamic linker names, each with corresponding build in 
build-many-glibcs.py, plus any other variants that are relevant to build 
in build-many-glibcs.py without being different ABIs, such as hard/soft 
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 02/15] ARC: ABI Implementation

[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 v4 02/15] ARC: ABI Implementation

[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

[PATCH v4 02/15] ARC: ABI Implementation

[Vineet Gupta]

This code deals with the ARC ABI.

Signed-off-by: Vineet Gupta 
---
 sysdeps/arc/__longjmp.S   | 50 ++
 sysdeps/arc/abort-instr.h |  2 +
 sysdeps/arc/bits/endianness.h | 15 +++
 sysdeps/arc/bits/setjmp.h | 26 
 sysdeps/arc/bsd-_setjmp.S |  1 +
 sysdeps/arc/bsd-setjmp.S  |  1 +
 sysdeps/arc/dl-runtime.c  | 39 +
 sysdeps/arc/dl-sysdep.h   | 25 +++
 sysdeps/arc/dl-trampoline.S   | 80 +++
 sysdeps/arc/gccframe.h| 21 +
 sysdeps/arc/gmp-mparam.h  | 23 ++
 sysdeps/arc/jmpbuf-offsets.h  | 47 
 sysdeps/arc/jmpbuf-unwind.h   | 47 
 sysdeps/arc/machine-gmon.h| 35 +++
 sysdeps/arc/memusage.h| 23 ++
 sysdeps/arc/setjmp.S  | 66 +
 sysdeps/arc/sysdep.h  | 48 +
 sysdeps/arc/tls-macros.h  | 47 
 18 files changed, 596 insertions(+)
 create mode 100644 sysdeps/arc/__longjmp.S
 create mode 100644 sysdeps/arc/abort-instr.h
 create mode 100644 sysdeps/arc/bits/endianness.h
 create mode 100644 sysdeps/arc/bits/setjmp.h
 create mode 100644 sysdeps/arc/bsd-_setjmp.S
 create mode 100644 sysdeps/arc/bsd-setjmp.S
 create mode 100644 sysdeps/arc/dl-runtime.c
 create mode 100644 sysdeps/arc/dl-sysdep.h
 create mode 100644 sysdeps/arc/dl-trampoline.S
 create mode 100644 sysdeps/arc/gccframe.h
 create mode 100644 sysdeps/arc/gmp-mparam.h
 create mode 100644 sysdeps/arc/jmpbuf-offsets.h
 create mode 100644 sysdeps/arc/jmpbuf-unwind.h
 create mode 100644 sysdeps/arc/machine-gmon.h
 create mode 100644 sysdeps/arc/memusage.h
 create mode 100644 sysdeps/arc/setjmp.S
 create mode 100644 sysdeps/arc/sysdep.h
 create mode 100644 sysdeps/arc/tls-macros.h

diff --git a/sysdeps/arc/__longjmp.S b/sysdeps/arc/__longjmp.S
new file mode 100644
index ..ffc3daa7de72
--- /dev/null
+++ b/sysdeps/arc/__longjmp.S
@@ -0,0 +1,50 @@
+/* longjmp for ARC.
+   Copyright (C) 2017-2020 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
+   .  */
+
+#include 
+#include 
+
+;@ r0 = jump buffer from which regs will be restored
+;@ r1 = value that setjmp( ) will return due to this longjmp
+
+ENTRY (__longjmp)
+
+   ld_s r13,   [r0]
+   ld_s r14,   [r0,4]
+   ld   r15,   [r0,8]
+   ld   r16,   [r0,12]
+   ld   r17,   [r0,16]
+   ld   r18,   [r0,20]
+   ld   r19,   [r0,24]
+   ld   r20,   [r0,28]
+   ld   r21,   [r0,32]
+   ld   r22,   [r0,36]
+   ld   r23,   [r0,40]
+   ld   r24,   [r0,44]
+   ld   r25,   [r0,48]
+
+   ld   blink, [r0,60]
+   ld   fp,[r0,52]
+   ld   sp,[r0,56]
+
+   mov.f  r0, r1   ; get the setjmp return value(due to longjmp) in place
+
+   j.d[blink]  ; to caller of setjmp location, right after the call
+   mov.z  r0, 1; can't let setjmp return 0 when it is due to longjmp
+
+END (__longjmp)
diff --git a/sysdeps/arc/abort-instr.h b/sysdeps/arc/abort-instr.h
new file mode 100644
index ..49f33613c404
--- /dev/null
+++ b/sysdeps/arc/abort-instr.h
@@ -0,0 +1,2 @@
+/* FLAG 1 is privilege mode only instruction, hence will crash any program.  */
+#define ABORT_INSTRUCTION asm ("flag 1")
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
+
+#endif /* bits/endianness.h */
diff --git a/sysdeps/arc/bits/setjmp.h b/sysdeps/arc/bits/setjmp.h
new file mode 100644
index ..333e5cce3bea
--- /dev/null
+++ b/sysdeps/arc/bits/setjmp.h
@@ -0,0 +1,26 @@
+/* Define the machine-dependent type `jmp_buf'.  ARC version.
+   Copyright (C) 1992-2020 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