| Message ID | 1548811555-24373-1-git-send-email-vgupta@synopsys.com |
|---|---|
| Headers | show |
| Series | glibc port to ARC processors | expand |
In the absence of clear consensus regarding consideration of new ports to undocumented architectures (which would need to result in consensus on suitable rules on the subject to go in <https://sourceware.org/glibc/wiki/NewPorts>), and in the absence of suitable public architecture and ABI documentation, I don't intend to attempt review of this or subsequent versions of the port submission. (I am supposing that the documentation available at <http://me.bios.io/ARC_disassembly> - which in any case does not include an ABI reference - is for an architecture version too old to be sufficient for understanding and maintaining the port code as may be needed in the course of glibc maintenance.)
On 1/29/19 6:29 PM, Joseph Myers wrote: > In the absence of clear consensus regarding consideration of new ports to > undocumented architectures (which would need to result in consensus on > suitable rules on the subject to go in > <https://sourceware.org/glibc/wiki/NewPorts>), and in the absence of > suitable public architecture and ABI documentation, I don't intend to > attempt review of this or subsequent versions of the port submission. That would be really unfortunate. Your prior reviews of RFC and v1 have been immensely helpful, it would be a shame to not continue to get this privilege goinf fwd. Having said that, wheels were already set in motion after your initial request in December. The ARCv2 ABI spec was opened up quickly (and mea culpa for not referencing it v2 submission). It is now publicly accessibly at [1] The public version of PRM is being worked on, but it will take time to come to fruition. I hope you appreciate these things take time, considering where we came from - and it seems you found a workaround anyways ;-) > (I > am supposing that the documentation available at > <http://me.bios.io/ARC_disassembly> - which in any case does not include > an ABI reference - is for an architecture version too old to be sufficient > for understanding and maintaining the port code as may be needed in the > course of glibc maintenance.) Not really. It sure pertains to the predecessor ARCompact ISA, but in ARCv2 the bulk of changes were to Interrupt architecture, micro-architecture optimizations, SMP support etc, which are not relevant for glibc or general userspace coding. While the encodings etc did change, much of the baseline instruction set is pretty much the same, so ARCv2 assembly or generated code easily maps to ARCompact. I do hope this is enough for you to reconsider reviewing the code. Thx, -Vineet [1] https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/wiki/files/ARCv2_ABI.pdf
On Wed, 30 Jan 2019, Vineet Gupta wrote: > Having said that, wheels were already set in motion after your initial request in > December. The ARCv2 ABI spec was opened up quickly (and mea culpa for not > referencing it v2 submission). It is now publicly accessibly at [1] Thanks. To be clear, the description at <https://sourceware.org/glibc/wiki/NewPorts> of what should go in the summary message for a new port submission should be considered to apply to every version of that submission, so that each submission is self-contained. That is, every version of the submission should include information such as pointers to relevant manuals (in addition to whatever's appropriate about changes from the previous version of the submission). > The public version of PRM is being worked on, but it will take time to > come to fruition. I hope you appreciate these things take time, > considering where we came from - and it seems you found a workaround > anyways ;-) There are five months until the freeze for 2.30 starts (obviously the port will need its symbol versions updated for 2.30).
Hi Joseph, On 1/30/19 10:15 AM, Vineet Gupta wrote: > On 1/29/19 6:29 PM, Joseph Myers wrote: >> In the absence of clear consensus regarding consideration of new ports to >> undocumented architectures (which would need to result in consensus on >> suitable rules on the subject to go in >> <https://sourceware.org/glibc/wiki/NewPorts>), and in the absence of >> suitable public architecture and ABI documentation, I don't intend to >> attempt review of this or subsequent versions of the port submission. > > That would be really unfortunate. Your prior reviews of RFC and v1 have been > immensely helpful, it would be a shame to not continue to get this privilege goinf > fwd. > > Having said that, wheels were already set in motion after your initial request in > December. The ARCv2 ABI spec was opened up quickly (and mea culpa for not > referencing it v2 submission). It is now publicly accessibly at [1] > > The public version of PRM is being worked on, but it will take time to come to > fruition. I hope you appreciate these things take time, considering where we came > from - and it seems you found a workaround anyways ;-) The public PRM is now available and I would like you to try and access it so that any bureaucracy is out of the way before I re-post ARC port for 2.32 ! Do note you still need to register to download but that is no different than say ARM. The landing page is https://www.synopsys.com/dw/ipdir.php?ds=arc-hs44-hs46-hs48 And there in the link to actual doc is https://www.synopsys.com/dw/doc.php/ds/cc/programmers-reference-manual-ARC-HS.pdf Let me know how it goes. Thx, -Vineet
On Fri, 17 Jan 2020, Vineet Gupta wrote: > The public PRM is now available and I would like you to try and access > it so that any bureaucracy is out of the way before I re-post ARC port > for 2.32 ! Thanks! There was one technical point regarding the glibc port I raised briefly in a discussion at the end of the Cauldron in Montreal: you should consider whether it would make sense, as a new 32-bit port, to have 64-bit times and 64-bit off_t, ino_t, etc. from the start, as RV32 is doing. We don't have a specific policy for this, but it may make sense for new ports not to include ABI variants that either are, or will become, obsolescent. If you require Linux 5.1 or later for the port then all or nearly all the architecture-independent pieces required for a 32-bit port supporting only 64-bit times should be covered by the RV32 patches, which I think are quite close to being ready to go into glibc, though you'd need to watch out for any (new or existing) #ifdef conditionals that might try to use 32-bit-time syscalls if they exist (which they don't on RV32) - and that would not prevent supporting older kernel versions later if desired, as the Y2038 support gets built out (including, in particular, the support for falling back to 32-bit-time syscalls in functions for 64-bit-time interfaces).
On 1/17/20 1:56 PM, Joseph Myers wrote: > There was one technical point regarding the glibc port I raised briefly in > a discussion at the end of the Cauldron in Montreal: you should consider > whether it would make sense, as a new 32-bit port, to have 64-bit times > and 64-bit off_t, ino_t, etc. from the start, as RV32 is doing. We don't > have a specific policy for this, but it may make sense for new ports not > to include ABI variants that either are, or will become, obsolescent. I agree we should do that. > If > you require Linux 5.1 or later for the port then all or nearly all the > architecture-independent pieces required for a 32-bit port supporting only > 64-bit times should be covered by the RV32 patches, which I think are > quite close to being ready to go into glibc, though you'd need to watch > out for any (new or existing) #ifdef conditionals that might try to use > 32-bit-time syscalls if they exist (which they don't on RV32) - and that > would not prevent supporting older kernel versions later if desired, as > the Y2038 support gets built out (including, in particular, the support > for falling back to 32-bit-time syscalls in functions for 64-bit-time > interfaces). Ok I see patches in flight on the mailing list. Would it make sense for me to start off in parallel with ARC port which will take it's due course of review and rework and in that process upstream y2038 work settles down and I then rebase/switch ARC to that. Or would rather wait for upstream to settle down and then I adjust/post ? Thx, -Vineet
On Thu, 6 Feb 2020, Vineet Gupta wrote: > > If > > you require Linux 5.1 or later for the port then all or nearly all the > > architecture-independent pieces required for a 32-bit port supporting only > > 64-bit times should be covered by the RV32 patches, which I think are > > quite close to being ready to go into glibc, though you'd need to watch > > out for any (new or existing) #ifdef conditionals that might try to use > > 32-bit-time syscalls if they exist (which they don't on RV32) - and that > > would not prevent supporting older kernel versions later if desired, as > > the Y2038 support gets built out (including, in particular, the support > > for falling back to 32-bit-time syscalls in functions for 64-bit-time > > interfaces). > > Ok I see patches in flight on the mailing list. Would it make sense for me to > start off in parallel with ARC port which will take it's due course of review and > rework and in that process upstream y2038 work settles down and I then > rebase/switch ARC to that. Or would rather wait for upstream to settle down and > then I adjust/post ? I'd suggest posting patches that are on top of the RV32 ones (maybe there's a git tree with RV32 changes to current glibc that could be used), and that only support Linux 5.1 and later (so you don't need anything much of the Y2038 support beyond what's in the RV32 patches).
On Thu, Feb 6, 2020 at 1:51 PM Joseph Myers <joseph@codesourcery.com> wrote: > > On Thu, 6 Feb 2020, Vineet Gupta wrote: > > > > If > > > you require Linux 5.1 or later for the port then all or nearly all the > > > architecture-independent pieces required for a 32-bit port supporting only > > > 64-bit times should be covered by the RV32 patches, which I think are > > > quite close to being ready to go into glibc, though you'd need to watch > > > out for any (new or existing) #ifdef conditionals that might try to use > > > 32-bit-time syscalls if they exist (which they don't on RV32) - and that > > > would not prevent supporting older kernel versions later if desired, as > > > the Y2038 support gets built out (including, in particular, the support > > > for falling back to 32-bit-time syscalls in functions for 64-bit-time > > > interfaces). > > > > Ok I see patches in flight on the mailing list. Would it make sense for me to > > start off in parallel with ARC port which will take it's due course of review and > > rework and in that process upstream y2038 work settles down and I then > > rebase/switch ARC to that. Or would rather wait for upstream to settle down and > > then I adjust/post ? > > I'd suggest posting patches that are on top of the RV32 ones (maybe > there's a git tree with RV32 changes to current glibc that could be used), > and that only support Linux 5.1 and later (so you don't need anything much > of the Y2038 support beyond what's in the RV32 patches). Go for it! My working branch is here: https://github.com/alistair23/glibc/tree/alistair/rv32.next My latest RFC branch is here: https://github.com/alistair23/glibc/tree/alistair/rv32.rfc6 Alistair > > -- > Joseph S. Myers > joseph@codesourcery.com
On 2/6/20 2:06 PM, Alistair Francis wrote: >> >> I'd suggest posting patches that are on top of the RV32 ones (maybe >> there's a git tree with RV32 changes to current glibc that could be used), >> and that only support Linux 5.1 and later (so you don't need anything much >> of the Y2038 support beyond what's in the RV32 patches). > > Go for it! > > My working branch is here: > https://github.com/alistair23/glibc/tree/alistair/rv32.next > > My latest RFC branch is here: > https://github.com/alistair23/glibc/tree/alistair/rv32.rfc6 Thx a bunch Alistair. I'm rebasing my stuff on top of your next branch as it seems to have more time/y2038 code so will help shake it out as well. Thx, -Vineet
Hi Vineet, > On 2/6/20 2:06 PM, Alistair Francis wrote: > >> > >> I'd suggest posting patches that are on top of the RV32 ones (maybe > >> there's a git tree with RV32 changes to current glibc that could > >> be used), and that only support Linux 5.1 and later (so you don't > >> need anything much of the Y2038 support beyond what's in the RV32 > >> patches). > > > > Go for it! > > > > My working branch is here: > > https://github.com/alistair23/glibc/tree/alistair/rv32.next > > > > My latest RFC branch is here: > > https://github.com/alistair23/glibc/tree/alistair/rv32.rfc6 > > Thx a bunch Alistair. I'm rebasing my stuff on top of your next > branch as it seems to have more time/y2038 code so will help shake it > out as well. If it may help a bit, please also review/check the current status of Y2038 work. Some Y2038 related work (mostly for ARM32) may be also helpful as well (as some patches for RV32 also do the conversion for other architectures). https://github.com/lmajewski/y2038_glibc/commits/y2038_edge Please also find the meta layer for testing Y2038 (with some basic test suite) code on qemu-arm and Yocto/OE: https://github.com/lmajewski/meta-y2038 (it shall also be easy to extend this meta layer to add support for ARC as well). > > Thx, > -Vineet Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
Hi, v2 of glibc port to ARC processors from Synopsys. Thx for reviewing the v1 [1], I've hopefully addressed all the comments. Any unlikely omissions are unintended. Also apologies for the bad timing given the imminent release, but that ship has likely already sailed, so we might as well continue our march independently. The main changes since v1 are * sigaction updates - drop sigaction.h, use generic version - sigaction.c to use generic linux/sigaction.c - arch specific __sigset_t.h to enable __sigset_t [2] vs. [128] * atomics: Enable USE_ATOMIC_COMPILER_BUILTINS * switch to init_array, removed crt{i,n} * Build: remove libc_cv_fpie=no * __startcontext: use cfi_undefined to terminate unwinder * dropped ldconfig.h, libnsl.abilist, cacheflush.c (use syscalls.list), procfs-id.h, math_private.h * cosmetics - Trying to follow the coding style and conventions - Folded the testsuite fixes patches into main port patches - Update copyright headers to 2019 Customary test results: Built against binutils-2_32-branch gcc-8-stable (commit 0d5ba57508c5 as of today with prerequisite backport) (a) build-many-glibcs.py | Summary of test results: | 1173 PASS # same as v1 | 15 XFAIL # same as v1 | | PASS: glibcs-arc-linux-gnu check (b) Full testsuite ran in a cross compile setup using buildroot on HSDK development platform. Full log at [2]. | Summary of test results: | 22 FAIL # 2 fewer than v1 | 5151 PASS # 27 more than v1 | 23 UNSUPPORTED # 4 fewer | 19 XFAIL # no change | | FAIL: localedata/sort-test | FAIL: stdio-common/bug22 | FAIL: sunrpc/bug20790 | FAIL: nptl/test-mutexattr-printers | FAIL: nptl/test-mutex-printers | FAIL: nptl/test-condattr-printers | FAIL: nptl/test-cond-printers | FAIL: nptl/test-rwlockattr-printers | FAIL: nptl/test-rwlock-printers | FAIL: iconv/test-iconvconfig | FAIL: posix/bug-ga2 | FAIL: posix/tst-getaddrinfo5 | FAIL: posix/globtest | FAIL: gmon/tst-sprofil | FAIL: io/ftwtest | FAIL: nptl/tst-cond17 | FAIL: nptl/tst-cond25 | FAIL: nptl/tst-umask1 | FAIL: nss/bug-erange | FAIL: nss/tst-nss-files-hosts-getent | FAIL: nss/tst-nss-files-hosts-multi | FAIL: nss/tst-nss-test3 Kindly review. Thx, -Vineet [1] https://sourceware.org/ml/libc-alpha/2018-12/msg00678.html [2] https://github.com/foss-for-synopsys-dwc-arc-processors/glibc/files/2810200/glibc-testsuite-results-commit-2f9a78f208a7.log.gz Vineet Gupta (15): ARC: add definitions to elf/elf.h ARC: ABI Implementation ARC: startup and dynamic linking code ARC: Thread Local Storage support ARC: Atomics and Locking primitives ARC: math soft float support ARC: Linux Syscall Interface ARC: Linux ABI ARC: Linux Startup and Dynamic Loading ARC: ABI lists ARC: Update syscall-names.list for ARC specific syscalls ARC: Build Infrastructure build-many-glibcs.py: Enable ARC builds NEWS: mention ARC port make-syscalls.sh: fix comment referencing syscall-template ChangeLog | 106 + NEWS | 7 + elf/elf.h | 70 +- scripts/build-many-glibcs.py | 4 + sysdeps/arc/Implies | 4 + sysdeps/arc/Makefile | 25 + sysdeps/arc/Versions | 6 + sysdeps/arc/__longjmp.S | 50 + sysdeps/arc/abort-instr.h | 2 + sysdeps/arc/atomic-machine.h | 73 + sysdeps/arc/bits/endian.h | 12 + sysdeps/arc/bits/fenv.h | 72 + sysdeps/arc/bits/link.h | 52 + sysdeps/arc/bits/setjmp.h | 26 + sysdeps/arc/bsd-_setjmp.S | 1 + sysdeps/arc/bsd-setjmp.S | 1 + sysdeps/arc/configure | 14 + sysdeps/arc/configure.ac | 11 + sysdeps/arc/dl-machine.h | 340 ++++ sysdeps/arc/dl-runtime.c | 39 + sysdeps/arc/dl-sysdep.h | 25 + sysdeps/arc/dl-tls.h | 30 + sysdeps/arc/dl-trampoline.S | 80 + sysdeps/arc/entry.h | 5 + 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/ldsodefs.h | 43 + sysdeps/arc/libc-tls.c | 27 + sysdeps/arc/machine-gmon.h | 35 + sysdeps/arc/memusage.h | 23 + sysdeps/arc/nofpu/Implies | 1 + sysdeps/arc/nofpu/libm-test-ulps | 390 ++++ sysdeps/arc/nofpu/libm-test-ulps-name | 1 + sysdeps/arc/nofpu/math-tests-exceptions.h | 27 + sysdeps/arc/nofpu/math-tests-rounding.h | 27 + sysdeps/arc/nptl/Makefile | 22 + sysdeps/arc/nptl/bits/pthreadtypes-arch.h | 72 + sysdeps/arc/nptl/bits/semaphore.h | 32 + sysdeps/arc/nptl/pthread-offsets.h | 5 + sysdeps/arc/nptl/pthreaddef.h | 32 + sysdeps/arc/nptl/tcb-offsets.sym | 11 + sysdeps/arc/nptl/tls.h | 150 ++ sysdeps/arc/preconfigure | 14 + sysdeps/arc/setjmp.S | 66 + sysdeps/arc/sfp-machine.h | 73 + sysdeps/arc/sotruss-lib.c | 51 + sysdeps/arc/stackinfo.h | 33 + sysdeps/arc/start.S | 89 + sysdeps/arc/sysdep.h | 48 + sysdeps/arc/tls-macros.h | 47 + sysdeps/arc/tst-audit.h | 23 + sysdeps/unix/make-syscalls.sh | 2 +- sysdeps/unix/sysv/linux/arc/Implies | 3 + sysdeps/unix/sysv/linux/arc/Makefile | 20 + sysdeps/unix/sysv/linux/arc/Versions | 16 + sysdeps/unix/sysv/linux/arc/bits/procfs.h | 35 + .../unix/sysv/linux/arc/bits/types/__sigset_t.h | 12 + sysdeps/unix/sysv/linux/arc/c++-types.data | 67 + sysdeps/unix/sysv/linux/arc/clone.S | 98 + sysdeps/unix/sysv/linux/arc/configure | 4 + sysdeps/unix/sysv/linux/arc/configure.ac | 4 + sysdeps/unix/sysv/linux/arc/dl-static.c | 84 + sysdeps/unix/sysv/linux/arc/getcontext.S | 63 + sysdeps/unix/sysv/linux/arc/ipc_priv.h | 21 + sysdeps/unix/sysv/linux/arc/jmp_buf-macros.h | 6 + sysdeps/unix/sysv/linux/arc/kernel-features.h | 28 + sysdeps/unix/sysv/linux/arc/ld.abilist | 9 + sysdeps/unix/sysv/linux/arc/ldsodefs.h | 32 + .../unix/sysv/linux/arc/libBrokenLocale.abilist | 1 + sysdeps/unix/sysv/linux/arc/libanl.abilist | 4 + sysdeps/unix/sysv/linux/arc/libc.abilist | 2089 ++++++++++++++++++++ sysdeps/unix/sysv/linux/arc/libcrypt.abilist | 2 + sysdeps/unix/sysv/linux/arc/libdl.abilist | 9 + sysdeps/unix/sysv/linux/arc/libm.abilist | 753 +++++++ sysdeps/unix/sysv/linux/arc/libpthread.abilist | 235 +++ sysdeps/unix/sysv/linux/arc/libresolv.abilist | 79 + sysdeps/unix/sysv/linux/arc/librt.abilist | 35 + sysdeps/unix/sysv/linux/arc/libthread_db.abilist | 40 + sysdeps/unix/sysv/linux/arc/libutil.abilist | 6 + sysdeps/unix/sysv/linux/arc/localplt.data | 16 + sysdeps/unix/sysv/linux/arc/makecontext.c | 75 + sysdeps/unix/sysv/linux/arc/mmap_internal.h | 27 + sysdeps/unix/sysv/linux/arc/profil-counter.h | 2 + sysdeps/unix/sysv/linux/arc/pt-vfork.S | 1 + sysdeps/unix/sysv/linux/arc/setcontext.S | 92 + sysdeps/unix/sysv/linux/arc/shlib-versions | 2 + sysdeps/unix/sysv/linux/arc/sigaction.c | 31 + sysdeps/unix/sysv/linux/arc/sigcontextinfo.h | 23 + sysdeps/unix/sysv/linux/arc/sigrestorer.S | 29 + sysdeps/unix/sysv/linux/arc/swapcontext.S | 92 + sysdeps/unix/sysv/linux/arc/sys/cachectl.h | 36 + sysdeps/unix/sysv/linux/arc/sys/ucontext.h | 63 + sysdeps/unix/sysv/linux/arc/sys/user.h | 31 + sysdeps/unix/sysv/linux/arc/syscall.S | 38 + sysdeps/unix/sysv/linux/arc/syscalls.list | 3 + sysdeps/unix/sysv/linux/arc/sysdep.c | 33 + sysdeps/unix/sysv/linux/arc/sysdep.h | 251 +++ sysdeps/unix/sysv/linux/arc/ucontext-macros.h | 29 + sysdeps/unix/sysv/linux/arc/ucontext_i.sym | 20 + sysdeps/unix/sysv/linux/arc/vfork.S | 42 + sysdeps/unix/sysv/linux/syscall-names.list | 3 + 103 files changed, 7229 insertions(+), 2 deletions(-) create mode 100644 sysdeps/arc/Implies create mode 100644 sysdeps/arc/Makefile create mode 100644 sysdeps/arc/Versions create mode 100644 sysdeps/arc/__longjmp.S create mode 100644 sysdeps/arc/abort-instr.h create mode 100644 sysdeps/arc/atomic-machine.h create mode 100644 sysdeps/arc/bits/endian.h create mode 100644 sysdeps/arc/bits/fenv.h create mode 100644 sysdeps/arc/bits/link.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/configure create mode 100644 sysdeps/arc/configure.ac create mode 100644 sysdeps/arc/dl-machine.h create mode 100644 sysdeps/arc/dl-runtime.c create mode 100644 sysdeps/arc/dl-sysdep.h create mode 100644 sysdeps/arc/dl-tls.h create mode 100644 sysdeps/arc/dl-trampoline.S create mode 100644 sysdeps/arc/entry.h 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/ldsodefs.h create mode 100644 sysdeps/arc/libc-tls.c create mode 100644 sysdeps/arc/machine-gmon.h create mode 100644 sysdeps/arc/memusage.h create mode 100644 sysdeps/arc/nofpu/Implies create mode 100644 sysdeps/arc/nofpu/libm-test-ulps create mode 100644 sysdeps/arc/nofpu/libm-test-ulps-name create mode 100644 sysdeps/arc/nofpu/math-tests-exceptions.h create mode 100644 sysdeps/arc/nofpu/math-tests-rounding.h create mode 100644 sysdeps/arc/nptl/Makefile create mode 100644 sysdeps/arc/nptl/bits/pthreadtypes-arch.h create mode 100644 sysdeps/arc/nptl/bits/semaphore.h create mode 100644 sysdeps/arc/nptl/pthread-offsets.h create mode 100644 sysdeps/arc/nptl/pthreaddef.h create mode 100644 sysdeps/arc/nptl/tcb-offsets.sym create mode 100644 sysdeps/arc/nptl/tls.h create mode 100644 sysdeps/arc/preconfigure create mode 100644 sysdeps/arc/setjmp.S create mode 100644 sysdeps/arc/sfp-machine.h create mode 100644 sysdeps/arc/sotruss-lib.c create mode 100644 sysdeps/arc/stackinfo.h create mode 100644 sysdeps/arc/start.S create mode 100644 sysdeps/arc/sysdep.h create mode 100644 sysdeps/arc/tls-macros.h create mode 100644 sysdeps/arc/tst-audit.h create mode 100644 sysdeps/unix/sysv/linux/arc/Implies create mode 100644 sysdeps/unix/sysv/linux/arc/Makefile create mode 100644 sysdeps/unix/sysv/linux/arc/Versions create mode 100644 sysdeps/unix/sysv/linux/arc/bits/procfs.h create mode 100644 sysdeps/unix/sysv/linux/arc/bits/types/__sigset_t.h create mode 100644 sysdeps/unix/sysv/linux/arc/c++-types.data create mode 100644 sysdeps/unix/sysv/linux/arc/clone.S create mode 100644 sysdeps/unix/sysv/linux/arc/configure create mode 100644 sysdeps/unix/sysv/linux/arc/configure.ac create mode 100644 sysdeps/unix/sysv/linux/arc/dl-static.c create mode 100644 sysdeps/unix/sysv/linux/arc/getcontext.S create mode 100644 sysdeps/unix/sysv/linux/arc/ipc_priv.h create mode 100644 sysdeps/unix/sysv/linux/arc/jmp_buf-macros.h create mode 100644 sysdeps/unix/sysv/linux/arc/kernel-features.h create mode 100644 sysdeps/unix/sysv/linux/arc/ld.abilist create mode 100644 sysdeps/unix/sysv/linux/arc/ldsodefs.h create mode 100644 sysdeps/unix/sysv/linux/arc/libBrokenLocale.abilist create mode 100644 sysdeps/unix/sysv/linux/arc/libanl.abilist create mode 100644 sysdeps/unix/sysv/linux/arc/libc.abilist create mode 100644 sysdeps/unix/sysv/linux/arc/libcrypt.abilist create mode 100644 sysdeps/unix/sysv/linux/arc/libdl.abilist create mode 100644 sysdeps/unix/sysv/linux/arc/libm.abilist create mode 100644 sysdeps/unix/sysv/linux/arc/libpthread.abilist create mode 100644 sysdeps/unix/sysv/linux/arc/libresolv.abilist create mode 100644 sysdeps/unix/sysv/linux/arc/librt.abilist create mode 100644 sysdeps/unix/sysv/linux/arc/libthread_db.abilist create mode 100644 sysdeps/unix/sysv/linux/arc/libutil.abilist create mode 100644 sysdeps/unix/sysv/linux/arc/localplt.data create mode 100644 sysdeps/unix/sysv/linux/arc/makecontext.c create mode 100644 sysdeps/unix/sysv/linux/arc/mmap_internal.h create mode 100644 sysdeps/unix/sysv/linux/arc/profil-counter.h create mode 100644 sysdeps/unix/sysv/linux/arc/pt-vfork.S create mode 100644 sysdeps/unix/sysv/linux/arc/setcontext.S create mode 100644 sysdeps/unix/sysv/linux/arc/shlib-versions create mode 100644 sysdeps/unix/sysv/linux/arc/sigaction.c create mode 100644 sysdeps/unix/sysv/linux/arc/sigcontextinfo.h create mode 100644 sysdeps/unix/sysv/linux/arc/sigrestorer.S create mode 100644 sysdeps/unix/sysv/linux/arc/swapcontext.S create mode 100644 sysdeps/unix/sysv/linux/arc/sys/cachectl.h create mode 100644 sysdeps/unix/sysv/linux/arc/sys/ucontext.h create mode 100644 sysdeps/unix/sysv/linux/arc/sys/user.h create mode 100644 sysdeps/unix/sysv/linux/arc/syscall.S create mode 100644 sysdeps/unix/sysv/linux/arc/syscalls.list create mode 100644 sysdeps/unix/sysv/linux/arc/sysdep.c create mode 100644 sysdeps/unix/sysv/linux/arc/sysdep.h create mode 100644 sysdeps/unix/sysv/linux/arc/ucontext-macros.h create mode 100644 sysdeps/unix/sysv/linux/arc/ucontext_i.sym create mode 100644 sysdeps/unix/sysv/linux/arc/vfork.S