| Message ID | 1545167083-16764-1-git-send-email-vgupta@synopsys.com |
|---|---|
| Headers | show |
| Series | glibc port to ARC processors | expand |
On Tue, 18 Dec 2018, Vineet Gupta wrote: > | FAIL: elf/check-localplt # passes for build-many-glibcs.py > # buildroot builds with slightly different toggles (-Os) > # such that gcc generates an extra memcpy PLT call I fixed lots of such issues with -Os on various architectures; it should be possible to fix this one as well. (I haven't run build-many-glibcs.py with -Os lately, so it's possible more problems have crept in or appear with current compilers. When I was testing it, it failed for m68k - the m68k libm functions don't build with -Os because bits/mathinline.h doesn't get included then, which needs addressing anyway in some way to eliminate bits/mathinline.h from glibc - but worked for most or all other configurations.) > (d) We currently only support soft float ABI, although I'm working on hard float > and hopefully will have it ready sometime during the review of this series Could you confirm what the ABI entry or entries to go at <https://sourceware.org/glibc/wiki/ABIList> would look like? Note that we generally expect new ports to use different dynamic linker names for each ABI. This means separate names for hard float and soft float. Since it appears you support both big and little endian, it also means separate dynamic linker names for each of those (and corresponding GCC changes will be needed to pass the right dynamic linker names to ld's -dynamic-linker option). Then, each supported ABI should have a build in build-many-glibcs.py, and any unsupported ABI variants need to have a configure-time error (to avoid accidentally building a glibc incompatible with the correct ABI for such a port added in future).
On 12/18/18 2:52 PM, Joseph Myers wrote: > On Tue, 18 Dec 2018, Vineet Gupta wrote: > >> | FAIL: elf/check-localplt # passes for build-many-glibcs.py >> # buildroot builds with slightly different toggles (-Os) >> # such that gcc generates an extra memcpy PLT call > > I fixed lots of such issues with -Os on various architectures; it should > be possible to fix this one as well. (I haven't run build-many-glibcs.py > with -Os lately, so it's possible more problems have crept in or appear > with current compilers. When I was testing it, it failed for m68k - the > m68k libm functions don't build with -Os because bits/mathinline.h doesn't > get included then, which needs addressing anyway in some way to eliminate > bits/mathinline.h from glibc - but worked for most or all other > configurations.) The actual xcheck runs posted later on have been with buildroot built toolchain which defaults to -Os, so it works for ARC, except for this additional entry. At any rate, the generated code will likely be different for -Os and otherwise, does that mean entries get added conditionally to localplt.data etc ? >> (d) We currently only support soft float ABI, although I'm working on hard float >> and hopefully will have it ready sometime during the review of this series > > Could you confirm what the ABI entry or entries to go at > <https://sourceware.org/glibc/wiki/ABIList> would look like? soft-float LE: ld-linux-arc.so.2 hard-float LE: ld-linux-archf.so.2 (although this is just a preference) > Note that we generally expect new ports to use different dynamic linker > names for each ABI. This means separate names for hard float and soft > float. Since it appears you support both big and little endian, it also > means separate dynamic linker names for each of those (and corresponding > GCC changes will be needed to pass the right dynamic linker names to ld's > -dynamic-linker option). ARC historically has supported both LE/BE, but we are kind of moving away from BE and as far as I know, there's no-one actively working with BE (except 1 specific customer with legact cores). It is safe to assume we won't support BE and this is sort of easier said for ARC processors as they have many many hardware config knobs and not all are supported for Linux usecase, so BE can be considered as such. > Then, each supported ABI should have a build in > build-many-glibcs.py, and any unsupported ABI variants need to have a > configure-time error (to avoid accidentally building a glibc incompatible > with the correct ABI for such a port added in future). Right, at this point I only have soft-float and work is ongoing for hard. Thx for taking a look. -Vineet
Another general point: when posting a new port, could you include pointers to architecture and ABI reference manuals in case those are of relevance to the review? (URLs going directly to PDFs of those manuals are preferred.)
On Tue, 18 Dec 2018, Vineet Gupta wrote: > At any rate, the generated code will likely be different for -Os and otherwise, > does that mean entries get added conditionally to localplt.data etc ? Entries *can* have a "?" to indicate they are optional (although avoiding the PLT reference is better - see how include/string.h does asm redirection of mempcpy and stpcpy, or likewise in sysdeps/wordsize-32/divdi3-symbol-hacks.h, for example). > ARC historically has supported both LE/BE, but we are kind of moving > away from BE and as far as I know, there's no-one actively working with > BE (except 1 specific customer with legact cores). It is safe to assume > we won't support BE and this is sort of easier said for ARC processors > as they have many many hardware config knobs and not all are supported > for Linux usecase, so BE can be considered as such. In that case, there should be a #error in bits/endian.h, or a configure-time error, or something like that, to make clear the glibc port does not support BE.
On 12/18/18 3:11 PM, Joseph Myers wrote: > Another general point: when posting a new port, could you include pointers > to architecture and ABI reference manuals in case those are of relevance > to the review? (URLs going directly to PDFs of those manuals are > preferred.) The PRM (Programmer's Reference Manual) is not open source and per corporate policy requires license agreement, signing NDA... The ABI doc as of today is not open as well, although I'm checking if we could share it and if not create equivalent content like some of the other guys on github etc. Thx for your understanding. -Vineet
On Wed, 19 Dec 2018, Vineet Gupta wrote: > On 12/18/18 3:11 PM, Joseph Myers wrote: > > Another general point: when posting a new port, could you include pointers > > to architecture and ABI reference manuals in case those are of relevance > > to the review? (URLs going directly to PDFs of those manuals are > > preferred.) > > The PRM (Programmer's Reference Manual) is not open source and per corporate > policy requires license agreement, signing NDA... It's very questionable whether we should consider a port for inclusion in glibc at all without public architecture documentation (that is, documentation of instruction semantics; not necessarily documentation of microarchitectural performance characteristics etc.). Various kinds of changes can require a developer to refer to documentation across the range of architectures supported by glibc, if something requires assembly implementations across architectures (e.g. some of Adhemerval's changes to thread cancellation; or when I added fegetmode / fesetmode, that required referring to various architecture documentation to identify what bits should be considered mode bits, on each architecture where floating-point status and control bits occupy a single register). (Non-NDA click-throughs, like the Arm one agreeing not to use the manual to find if Arm implementations violate any patents, are OK, presuming there is nothing to restrict public discussion of the contents and using the information therein to develop free software, although having a direct URL to the manual without needing such a click-through is certainly preferred.)
On 12/19/18 4:14 PM, Joseph Myers wrote: > On Wed, 19 Dec 2018, Vineet Gupta wrote: > >> On 12/18/18 3:11 PM, Joseph Myers wrote: >>> Another general point: when posting a new port, could you include pointers >>> to architecture and ABI reference manuals in case those are of relevance >>> to the review? (URLs going directly to PDFs of those manuals are >>> preferred.) >> >> The PRM (Programmer's Reference Manual) is not open source and per corporate >> policy requires license agreement, signing NDA... > > It's very questionable whether we should consider a port for inclusion in > glibc at all without public architecture documentation IMHO this seems excessive. We've successfully open-sourced significant ports such as Linux kernel, gcc, binutils etc. gcc atleast deals with instruction semantics at a much closer level than glibc perse and that didn't get in the way then. Being an open source developer myself I agree with your reservations, but the reality is what Ted Tso so nicely put in at [1] | "It's something I do worry about; and I do share your concern. At the | same time, the reality is that we are a little like the Old Dutch | Masters, who had take into account the preference of their patrons | (i.e., in our case, those who pay our paychecks :-)" [1] https://lwn.net/Articles/446626/ > (that is, > documentation of instruction semantics; not necessarily documentation of > microarchitectural performance characteristics etc.). I understand the intent is all good faith and justified... > Various kinds of > changes can require a developer to refer to documentation across the range > of architectures supported by glibc, if something requires assembly > implementations across architectures (e.g. some of Adhemerval's changes to > thread cancellation; or when I added fegetmode / fesetmode, that required > referring to various architecture documentation to identify what bits > should be considered mode bits, on each architecture where floating-point > status and control bits occupy a single register). To be honest folks on lkml do sweeping arch changes, PeterZ is one good example and he has infact changed ARC assembly at times w/o access to PRM. Given the arrangement we have now, perhaps such changes can call in for review from port maintainer etc. > (Non-NDA click-throughs, like the Arm one agreeing not to use the manual > to find if Arm implementations violate any patents, are OK No that is not possible: I've discussed this with power may-be in the past and again today and this is not going to happen. Thx, -Vineet
On 12/18/18 1:04 PM, Vineet Gupta wrote: > (a) build-many-glibcs.py check results are clean > > | Summary of test results: > | 1173 PASS > | 15 XFAIL > | > | PASS: glibcs-arc-linux-gnu check One of the issues in running build-many incrementally, i.e. "host-libraries", "compilers" only once but "glibcs" again to quickly test fixes is that for 2nd run, target c++ compiler is picked up for support/links-dso-program vs. links-dso-program-c which fails as the cpp headers are not present. Is there a solution to that ? > (b) Full testsuite ran in a cross compile setup using buildroot on HSDK development > platform. > > Summary of test results: > 24 FAIL > 5124 PASS > 27 UNSUPPORTED > 19 XFAIL One of the pesky issues with cross testing is localedata/gen-locale.sh kicking on target, which despite being 1GHz gets in the way of quick iterations. Is there a way to build those on host and simply reference/install them on target. I understand this is more of a buildsystem question (buildroot), but any pointers would be appreciated.
On Thu, 20 Dec 2018, Vineet Gupta wrote: > On 12/18/18 1:04 PM, Vineet Gupta wrote: > > (a) build-many-glibcs.py check results are clean > > > > | Summary of test results: > > | 1173 PASS > > | 15 XFAIL > > | > > | PASS: glibcs-arc-linux-gnu check > > One of the issues in running build-many incrementally, i.e. "host-libraries", > "compilers" only once but "glibcs" again to quickly test fixes is that for 2nd > run, target c++ compiler is picked up for support/links-dso-program vs. > links-dso-program-c which fails as the cpp headers are not present. Is there a > solution to that ? I'm not aware of that problem. The C++ headers certainly should be available in the compilers installed by the "compilers" step. My bots using GCC 7 and 8 branches only rebuild the compilers once a week unless build-many-glibcs.py itself changes. > One of the pesky issues with cross testing is localedata/gen-locale.sh > kicking on target, which despite being 1GHz gets in the way of quick > iterations. Is there a way to build those on host and simply > reference/install them on target. I understand this is more of a > buildsystem question (buildroot), but any pointers would be appreciated. It's possible to set up an external build system that extracts the list of locales for testing from localedata/Makefile, builds them using the same version of localedef built for the build system and appropriate options for endianness and uint32_t alignment (if necessary) and copies them into the right places in the glibc build tree before running the glibc tests. It does have to be the same version of localedef since the binary locale format can change depending on the glibc version.
On 12/18/18 3:52 PM, Joseph Myers wrote: > On Tue, 18 Dec 2018, Vineet Gupta wrote: > >> At any rate, the generated code will likely be different for -Os and otherwise, >> does that mean entries get added conditionally to localplt.data etc ? > > Entries *can* have a "?" to indicate they are optional OK. > (although avoiding > the PLT reference is better - see how include/string.h does asm > redirection of mempcpy and stpcpy, or likewise in > sysdeps/wordsize-32/divdi3-symbol-hacks.h, for example). In libc.so, the extra PLT entry for memcpy | 00106034 00047837 R_ARC_JMP_SLOT 00066d5c memcpy@@GLIBC_2.27 + 0 | ... | 1bec8: ld r12,[pcl,0xea16c] ;106034 <memcpy@@GLIBC_2.27+0x9f2d8> | 1bed0: j.d [r12] | 1bed4: mov r12,pcl is due to linkage of a generic libgcc routine fp-bit.c | 000d79c4 <_fpadd_parts>: |... | d7a1a: bl -768848 ;1bec8 <.plt+0xd0> | that in turn is likely due to struct assignment in the routine |static const fp_number_type * |_fpadd_parts (fp_number_type * a, | fp_number_type * b, | fp_number_type * tmp) |{ | ... | if (iszero (a)) | { | *tmp = *a; So this is classic case of gcc -Os in action, generating a memcpy vs. in-place LD/ST based copy. So I guess we just add "?" to localplt.data >> ARC historically has supported both LE/BE, but we are kind of moving >> away from BE and as far as I know, there's no-one actively working with >> BE (except 1 specific customer with legact cores). It is safe to assume >> we won't support BE and this is sort of easier said for ARC processors >> as they have many many hardware config knobs and not all are supported >> for Linux usecase, so BE can be considered as such. > > In that case, there should be a #error in bits/endian.h, or a > configure-time error, or something like that, to make clear the glibc port > does not support BE. OK, I'll add that.
On Fri, 21 Dec 2018, Vineet Gupta wrote:
> is due to linkage of a generic libgcc routine fp-bit.c
I'd suggest moving from fp-bit to soft-fp in libgcc (soft-fp is a lot
faster, see the 2006 GCC Summit proceedings, though of course you may wish
to do your own benchmarking on ARC), which would probably avoid that issue
(though if very concerned about about code size, soft-fp is a bit larger).
But the "?" in localplt.data would still make sense as long as the GCC
versions using fp-bit there are supported for building the ARC glibc port.
On 12/21/18 6:32 AM, Joseph Myers wrote: > On Fri, 21 Dec 2018, Vineet Gupta wrote: > >> is due to linkage of a generic libgcc routine fp-bit.c > > I'd suggest moving from fp-bit to soft-fp in libgcc (soft-fp is a lot > faster, see the 2006 GCC Summit proceedings, though of course you may wish > to do your own benchmarking on ARC), which would probably avoid that issue It seems the we have "assisted" soft-fp: hand tweaked assembler written originally by Joern, so he and/or Claudiu can advise on that. Although the asm was tweaked for prev core/micro-architecture it should likely be faster than generic "C" code I presume. > (though if very concerned about about code size, soft-fp is a bit larger). Not for glibc :-) (uClibc is a different story, but it seems with largers RAMs and disks size is kind of becoming moot unless deeply embedded. > But the "?" in localplt.data would still make sense as long as the GCC > versions using fp-bit there are supported for building the ARC glibc port. Right, added that already.
Hi, This is reposting of glibc port to ARC processors from synopsys. The original posting was a while back [1]. The issues at the time were (1). Need for working upstream gcc/binutils (vs. the github forks) (2). Too many testsuite failures. All the ducks seem to be in a row now, with last remaining gcc patch backported to gcc-8-branch last week [2] and testsuite failures tended to/reduced significantly. (a) build-many-glibcs.py check results are clean | Summary of test results: | 1173 PASS | 15 XFAIL | | PASS: glibcs-arc-linux-gnu check (b) Full testsuite ran in a cross compile setup using buildroot on HSDK development platform. Summary of test results: 24 FAIL 5124 PASS 27 UNSUPPORTED 19 XFAIL | FAIL: localedata/sort-test # Needs more RAM: | FAIL: stdio-common/bug22 # Needs more RAM: 2 GB memory | FAIL: sunrpc/bug20790 # missing cpp on target | FAIL: nptl/test-mutexattr-printers # need Python3 and target GDB on target | FAIL: nptl/test-mutex-printers # need Python3 and target GDB on target | FAIL: nptl/test-condattr-printers # need Python3 and target GDB on target | FAIL: nptl/test-cond-printers # need Python3 and target GDB on target | FAIL: nptl/test-rwlockattr-printers # need Python3 and target GDB on target | FAIL: nptl/test-rwlock-printers # need Python3 and target GDB on target | FAIL: iconv/test-iconvconfig # Needs gconv installed | FAIL: posix/bug-ga2 # DNS issue: google DNS vs. SNPS | FAIL: posix/tst-getaddrinfo5 # DNS server not configured | FAIL: posix/globtest # require same user on target and host | FAIL: elf/check-localplt # passes for build-many-glibcs.py # buildroot builds with slightly different toggles (-Os) # such that gcc generates an extra memcpy PLT call | FAIL: gmon/tst-gmon-pie-gprof | FAIL: gmon/tst-sprofil | FAIL: posix/tst-spawn | FAIL: posix/tst-spawn-static | FAIL: nptl/tst-cond16 | FAIL: nptl/tst-cond17 | FAIL: nptl/tst-umask1 | FAIL: nptl/tst-setuid2 | FAIL: nss/bug-erange | FAIL: nss/tst-nss-test3 The full log for above can be found at [3] Bulk of failures are due to cross test setup and/or RAM accessible on target. We are analysing the other failures and will tend to them as we go along. (c) Code was rebased off of master yesterday. Please review and comment. (d) We currently only support soft float ABI, although I'm working on hard float and hopefully will have it ready sometime during the review of this series Thx, -Vineet [1] https://sourceware.org/ml/libc-alpha/2017-06/msg01355.html [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88001 [3] https://github.com/foss-for-synopsys-dwc-arc-processors/glibc/issues/1 Cupertino Miranda (2): ARC: testsuite fix: GD TLS issue ARC: fix several unwining and cancelation tests Vineet Gupta (19): longlong.h: sync from gcc to fix ARC inline asm constraints 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 ARC: Enable __start as entry point vs. canonical _start ARC: testsuite fix: elf/check-initfini ARC: testsuite fix: sysvipc/* ARC: testsuite fix: stdlib/tst-makecontext build-many-glibcs.py: Enable ARC builds NEWS: mention ARC port ChangeLog | 127 ++ NEWS | 2 + elf/elf.h | 70 +- scripts/build-many-glibcs.py | 4 + stdlib/longlong.h | 65 +- sysdeps/arc/Implies | 3 + sysdeps/arc/Makefile | 25 + sysdeps/arc/Versions | 14 + sysdeps/arc/__longjmp.S | 50 + sysdeps/arc/abort-instr.h | 2 + sysdeps/arc/atomic-machine.h | 89 + sysdeps/arc/bits/endian.h | 12 + sysdeps/arc/bits/fenv.h | 92 + sysdeps/arc/bits/link.h | 52 + sysdeps/arc/bits/setjmp.h | 33 + sysdeps/arc/bsd-_setjmp.S | 1 + sysdeps/arc/bsd-setjmp.S | 1 + sysdeps/arc/configure | 17 + sysdeps/arc/configure.ac | 13 + sysdeps/arc/crti.S | 79 + sysdeps/arc/crtn.S | 56 + sysdeps/arc/dl-machine.h | 339 ++++ sysdeps/arc/dl-runtime.c | 21 + sysdeps/arc/dl-sysdep.h | 25 + sysdeps/arc/dl-tls.h | 30 + sysdeps/arc/dl-trampoline.S | 81 + sysdeps/arc/entry.h | 5 + sysdeps/arc/gccframe.h | 21 + sysdeps/arc/gmp-mparam.h | 23 + sysdeps/arc/jmpbuf-offsets.h | 46 + sysdeps/arc/jmpbuf-unwind.h | 47 + sysdeps/arc/ldsodefs.h | 43 + sysdeps/arc/libc-tls.c | 27 + sysdeps/arc/machine-gmon.h | 33 + sysdeps/arc/math_private.h | 6 + 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-exception.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 | 64 + sysdeps/arc/sfp-machine.h | 51 + sysdeps/arc/sotruss-lib.c | 51 + sysdeps/arc/stackinfo.h | 33 + sysdeps/arc/start.S | 89 + sysdeps/arc/sysdep.h | 51 + sysdeps/arc/tls-macros.h | 29 + sysdeps/arc/tst-audit.h | 23 + 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-id.h | 25 + sysdeps/unix/sysv/linux/arc/bits/procfs.h | 35 + sysdeps/unix/sysv/linux/arc/bits/sigaction.h | 85 + sysdeps/unix/sysv/linux/arc/c++-types.data | 67 + sysdeps/unix/sysv/linux/arc/cacheflush.c | 29 + sysdeps/unix/sysv/linux/arc/clone.S | 100 + 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 | 65 + 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/ldconfig.h | 25 + 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/libnsl.abilist | 120 ++ 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 | 15 + sysdeps/unix/sysv/linux/arc/makecontext.c | 75 + sysdeps/unix/sysv/linux/arc/mmap_internal.h | 26 + 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 | 95 + sysdeps/unix/sysv/linux/arc/shlib-versions | 2 + sysdeps/unix/sysv/linux/arc/sigaction.c | 63 + sysdeps/unix/sysv/linux/arc/sigcontextinfo.h | 23 + sysdeps/unix/sysv/linux/arc/sigrestorer.S | 28 + 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 | 71 + sysdeps/unix/sysv/linux/arc/sys/user.h | 32 + sysdeps/unix/sysv/linux/arc/syscall.S | 38 + sysdeps/unix/sysv/linux/arc/sysdep.c | 33 + sysdeps/unix/sysv/linux/arc/sysdep.h | 259 +++ 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 + 109 files changed, 7709 insertions(+), 59 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/crti.S create mode 100644 sysdeps/arc/crtn.S 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/math_private.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-exception.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-id.h create mode 100644 sysdeps/unix/sysv/linux/arc/bits/procfs.h create mode 100644 sysdeps/unix/sysv/linux/arc/bits/sigaction.h create mode 100644 sysdeps/unix/sysv/linux/arc/c++-types.data create mode 100644 sysdeps/unix/sysv/linux/arc/cacheflush.c 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/ldconfig.h 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/libnsl.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/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