[00/21] glibc port to ARC processors

Message ID 1545167083-16764-1-git-send-email-vgupta@synopsys.com
Headers show
Series
  • glibc port to ARC processors
Related show

Message

Vineet Gupta Dec. 18, 2018, 9:04 p.m.
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

-- 
2.7.4

Comments

Joseph Myers Dec. 18, 2018, 10:52 p.m. | #1
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).

-- 
Joseph S. Myers
joseph@codesourcery.com
Vineet Gupta Dec. 18, 2018, 11:07 p.m. | #2
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
Joseph Myers Dec. 18, 2018, 11:11 p.m. | #3
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.)

-- 
Joseph S. Myers
joseph@codesourcery.com
Joseph Myers Dec. 18, 2018, 11:52 p.m. | #4
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.

-- 
Joseph S. Myers
joseph@codesourcery.com
Vineet Gupta Dec. 19, 2018, 11:45 p.m. | #5
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
Joseph Myers Dec. 20, 2018, 12:14 a.m. | #6
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.)

-- 
Joseph S. Myers
joseph@codesourcery.com
Vineet Gupta Dec. 20, 2018, 12:51 a.m. | #7
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
Vineet Gupta Dec. 20, 2018, 9:22 p.m. | #8
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.
Joseph Myers Dec. 20, 2018, 9:59 p.m. | #9
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.

-- 
Joseph S. Myers
joseph@codesourcery.com
Vineet Gupta Dec. 21, 2018, 1:55 a.m. | #10
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.
Joseph Myers Dec. 21, 2018, 2:32 p.m. | #11
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.

-- 
Joseph S. Myers
joseph@codesourcery.com
Vineet Gupta Dec. 21, 2018, 5:36 p.m. | #12
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.