[v4,00/10] RISC-V glibc port for the 32-bit

Message ID cover.1543572707.git.zongbox@gmail.com
Headers show
Series
  • RISC-V glibc port for the 32-bit
Related show

Message

Zong Li Dec. 1, 2018, 3:10 a.m.
This patchset contains the glibc port for the RISC-V 32-bit. In this version, we
collect the suggestions of previous version, use the same ULPs of hard-float and
soft-float both rv32 and rv64, and fixed failures about math cases as following:

The signal NaN problem is fixed in GCC:
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00356.html

The soft-fp problem had been fixed in Glibc and GCC:
https://sourceware.org/ml/libc-alpha/2018-11/msg00010.html
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00414.html

The necessary soft-fp functions for rv32 had been added in Glibc:
https://sourceware.org/ml/libc-alpha/2018-11/msg00009.html

We have less than 15 failures cases, these cases had been clarified on RV64 port
when released in glibc 2.27. The all *.out and *.test-result files of test result
as following:
https://github.com/andestech/glibc_test_result/blob/master/rv32_test_result.tar.gz

We ran the glibc test suite on Linux 4.19. Hope we could let the rv32 port enter
the mainline before code frozen and modify the Y2038 issue as soon before the
release date of glibc 2.29.

Very appreciate everyone who has helped review and fix issues.

Change in V4:
 - Use same ulp files of hard-float both rv32 and rv64
 - Re-generate the ABI list and ulp files
 - Add fix-fp-int-convert-overflow.h file

Change in V3:
 - Merge rv32/nofpu and rv64/nofpu directories
 - Remove ulp files of nofpu of 32-bit
 - Re-gen abilist for 2.29
 - Change section to 2.29 in NEWS

Change in V2:
 - Only include the ieee754/soft-fp path in rv32/nofpu/Implies.
 - Add lack of implementation for 128 bit in soft-ft/op-8.h.
 - Include the patch which fix the ld flags of tst-execstack-mod.so.
 - Add the modification of URL of gcc's tarball.

Zong Li (10):
  Documentation for the RISC-V 32-bit port
  RISC-V: Support dynamic loader for the 32-bit
  RISC-V: Add path of library directories for the 32-bit
  RISC-V: The ABI implementation for the 32-bit
  RISC-V: Hard float support for the 32 bit
  RISC-V: Regenerate ULPs of RISC-V
  RISC-V: Add ABI lists
  RISC-V: Build Infastructure for the 32-bit
  RISC-V: Fix llrint and llround missing exceptions on RV32
  Add RISC-V 32-bit target to build-many-glibcs.py

 ChangeLog                                          |   47 +
 NEWS                                               |    6 +
 README                                             |    1 +
 scripts/build-many-glibcs.py                       |   15 +
 sysdeps/riscv/bits/wordsize.h                      |    4 +-
 sysdeps/riscv/nofpu/libm-test-ulps                 |   24 +-
 sysdeps/riscv/nptl/bits/pthreadtypes-arch.h        |   25 +-
 sysdeps/riscv/preconfigure                         |    6 +-
 sysdeps/riscv/rv32/Implies-after                   |    1 +
 sysdeps/riscv/rv32/fix-fp-int-convert-overflow.h   |   38 +
 sysdeps/riscv/rv32/rvd/Implies                     |    3 +
 sysdeps/riscv/rv32/rvd/s_lrint.c                   |   31 +
 sysdeps/riscv/rv32/rvd/s_lround.c                  |   31 +
 sysdeps/riscv/rv32/rvf/Implies                     |    1 +
 sysdeps/riscv/rv32/rvf/s_lrintf.c                  |   31 +
 sysdeps/riscv/rv32/rvf/s_lroundf.c                 |   31 +
 sysdeps/riscv/rv64/rvd/libm-test-ulps              | 2206 -------------------
 sysdeps/riscv/rv64/rvd/libm-test-ulps-name         |    1 -
 sysdeps/riscv/rvd/libm-test-ulps                   | 2224 ++++++++++++++++++++
 sysdeps/riscv/rvd/libm-test-ulps-name              |    1 +
 sysdeps/riscv/sfp-machine.h                        |   27 +-
 sysdeps/riscv/sys/asm.h                            |    5 +-
 sysdeps/unix/sysv/linux/riscv/Makefile             |    4 +-
 sysdeps/unix/sysv/linux/riscv/configure            |   39 +
 sysdeps/unix/sysv/linux/riscv/configure.ac         |    8 +
 sysdeps/unix/sysv/linux/riscv/dl-cache.h           |   15 +-
 sysdeps/unix/sysv/linux/riscv/ldconfig.h           |    2 +-
 sysdeps/unix/sysv/linux/riscv/rv32/Implies         |    3 +
 sysdeps/unix/sysv/linux/riscv/rv32/c++-types.data  |   67 +
 .../unix/sysv/linux/riscv/rv32/jmp_buf-macros.h    |   53 +
 sysdeps/unix/sysv/linux/riscv/rv32/ld.abilist      |    9 +
 .../sysv/linux/riscv/rv32/libBrokenLocale.abilist  |    1 +
 sysdeps/unix/sysv/linux/riscv/rv32/libanl.abilist  |    4 +
 sysdeps/unix/sysv/linux/riscv/rv32/libc.abilist    | 2100 ++++++++++++++++++
 .../unix/sysv/linux/riscv/rv32/libcrypt.abilist    |    2 +
 sysdeps/unix/sysv/linux/riscv/rv32/libdl.abilist   |    9 +
 sysdeps/unix/sysv/linux/riscv/rv32/libm.abilist    | 1021 +++++++++
 sysdeps/unix/sysv/linux/riscv/rv32/libnsl.abilist  |  120 ++
 .../unix/sysv/linux/riscv/rv32/libpthread.abilist  |  235 +++
 .../unix/sysv/linux/riscv/rv32/libresolv.abilist   |   79 +
 sysdeps/unix/sysv/linux/riscv/rv32/librt.abilist   |   35 +
 .../sysv/linux/riscv/rv32/libthread_db.abilist     |   40 +
 sysdeps/unix/sysv/linux/riscv/rv32/libutil.abilist |    6 +
 sysdeps/unix/sysv/linux/riscv/rv32/lockf64.c       |   70 +
 sysdeps/unix/sysv/linux/riscv/shlib-versions       |   10 +-
 45 files changed, 6462 insertions(+), 2229 deletions(-)
 create mode 100644 sysdeps/riscv/rv32/Implies-after
 create mode 100644 sysdeps/riscv/rv32/fix-fp-int-convert-overflow.h
 create mode 100644 sysdeps/riscv/rv32/rvd/Implies
 create mode 100644 sysdeps/riscv/rv32/rvd/s_lrint.c
 create mode 100644 sysdeps/riscv/rv32/rvd/s_lround.c
 create mode 100644 sysdeps/riscv/rv32/rvf/Implies
 create mode 100644 sysdeps/riscv/rv32/rvf/s_lrintf.c
 create mode 100644 sysdeps/riscv/rv32/rvf/s_lroundf.c
 delete mode 100644 sysdeps/riscv/rv64/rvd/libm-test-ulps
 delete mode 100644 sysdeps/riscv/rv64/rvd/libm-test-ulps-name
 create mode 100644 sysdeps/riscv/rvd/libm-test-ulps
 create mode 100644 sysdeps/riscv/rvd/libm-test-ulps-name
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/Implies
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/c++-types.data
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/jmp_buf-macros.h
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/ld.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libBrokenLocale.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libanl.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libc.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libcrypt.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libdl.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libm.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libnsl.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libpthread.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libresolv.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/librt.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libthread_db.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libutil.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/lockf64.c

-- 
2.7.4

Comments

Joseph Myers Dec. 3, 2018, 6:04 p.m. | #1
Could you confirm the ABI entries that would be added to 
<https://sourceware.org/glibc/wiki/ABIList>?

Could you confirm the minimum upstream kernel version that supports 32-bit 
RISC-V with the syscall ABI that will remain supported long-term?  Is it 
4.15, or a later version?  (If a later version, arch_minimum_kernel needs 
to be set accordingly.)

-- 
Joseph S. Myers
joseph@codesourcery.com
Zong Li Dec. 7, 2018, 9:51 a.m. | #2
Joseph Myers <joseph@codesourcery.com> 於 2018年12月4日 週二 上午2:04寫道:
>

> Could you confirm the ABI entries that would be added to

> <https://sourceware.org/glibc/wiki/ABIList>?


We would need to add the ABI entries as following:
32-bit, soft-float, LE: /lib/ld-linux-riscv32-ilp32.so.1
32-bit, hard-float, LE: /lib/ld-linux-riscv32-ilp32d.so.1

> Could you confirm the minimum upstream kernel version that supports 32-bit

> RISC-V with the syscall ABI that will remain supported long-term?  Is it

> 4.15, or a later version?  (If a later version, arch_minimum_kernel needs

> to be set accordingly.)

>

I had checked with Palmer, and Palmer would confirm this here.
Palmer Dabbelt Dec. 8, 2018, 8:08 p.m. | #3
On Fri, 07 Dec 2018 01:51:46 PST (-0800), zongbox@gmail.com wrote:
> Joseph Myers <joseph@codesourcery.com> 於 2018年12月4日 週二 上午2:04寫道:

>>

>> Could you confirm the ABI entries that would be added to

>> <https://sourceware.org/glibc/wiki/ABIList>?

>

> We would need to add the ABI entries as following:

> 32-bit, soft-float, LE: /lib/ld-linux-riscv32-ilp32.so.1

> 32-bit, hard-float, LE: /lib/ld-linux-riscv32-ilp32d.so.1

>

>> Could you confirm the minimum upstream kernel version that supports 32-bit

>> RISC-V with the syscall ABI that will remain supported long-term?  Is it

>> 4.15, or a later version?  (If a later version, arch_minimum_kernel needs

>> to be set accordingly.)

>>

> I had checked with Palmer, and Palmer would confirm this here.


Sorry for the confusion.  A few of us sat down at the toolchain microconference 
at Plumbers and we decided it would be best to wait until the 32-bit Linux port 
is ready to support a 64-bit time_t ABI.  This isn't ready yet and won't be 
ready in time for the glibc freeze.

The options considered were to:

* Submit this port, which matches the current Linux ABI.  This has been stable 
  since 4.15.
* Try to push all the 64-bit time_t stuff into the next releases, so Linux 
  4.21 (which is not out yet).
* Wait until after the next glibc release and then submit the port, ideally 
  also against Linux 4.21.

We all decided to wait, as if we submit this now we'll end up with a RV32I 
glibc port that's 32-bit time_t.  We'd then have to go do another 64-bit time_t 
port along with everyone else, thus making this original port obsolete -- we'd 
have to support the 32-bit time_t port forever, which seems like a headache.

The plan we came up with was to instead:

* Review this port as if it was to be submitted, so we can sort out the issues.
* Produce an out-of-tree 32-bit time_t port, based on the upcoming glibc 
  release, that we can then use the bring up the port of at least one distro.  
  I know OpenEmbedded is coming up for RV32I, which would give me a lot more 
  confidence we have an actual working port.
* Submit the port after the upcoming release in February.
* Fix both Linux (for 4.21) and our glibc port to use a 64-bit time_t ABI, 
  which should be possible at least for all core kernel functionality.

I know Zong was at Plumbers, maybe you missed the tool chain thing?

Is this OK with everyone?
Andrew Waterman Dec. 8, 2018, 9:33 p.m. | #4
On Sat, Dec 8, 2018 at 12:09 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>

> On Fri, 07 Dec 2018 01:51:46 PST (-0800), zongbox@gmail.com wrote:

> > Joseph Myers <joseph@codesourcery.com> 於 2018年12月4日 週二 上午2:04寫道:

> >>

> >> Could you confirm the ABI entries that would be added to

> >> <https://sourceware.org/glibc/wiki/ABIList>?

> >

> > We would need to add the ABI entries as following:

> > 32-bit, soft-float, LE: /lib/ld-linux-riscv32-ilp32.so.1

> > 32-bit, hard-float, LE: /lib/ld-linux-riscv32-ilp32d.so.1

> >

> >> Could you confirm the minimum upstream kernel version that supports 32-bit

> >> RISC-V with the syscall ABI that will remain supported long-term?  Is it

> >> 4.15, or a later version?  (If a later version, arch_minimum_kernel needs

> >> to be set accordingly.)

> >>

> > I had checked with Palmer, and Palmer would confirm this here.

>

> Sorry for the confusion.  A few of us sat down at the toolchain microconference

> at Plumbers and we decided it would be best to wait until the 32-bit Linux port

> is ready to support a 64-bit time_t ABI.  This isn't ready yet and won't be

> ready in time for the glibc freeze.

>

> The options considered were to:

>

> * Submit this port, which matches the current Linux ABI.  This has been stable

>   since 4.15.

> * Try to push all the 64-bit time_t stuff into the next releases, so Linux

>   4.21 (which is not out yet).

> * Wait until after the next glibc release and then submit the port, ideally

>   also against Linux 4.21.

>

> We all decided to wait, as if we submit this now we'll end up with a RV32I

> glibc port that's 32-bit time_t.  We'd then have to go do another 64-bit time_t

> port along with everyone else, thus making this original port obsolete -- we'd

> have to support the 32-bit time_t port forever, which seems like a headache.

>

> The plan we came up with was to instead:

>

> * Review this port as if it was to be submitted, so we can sort out the issues.

> * Produce an out-of-tree 32-bit time_t port, based on the upcoming glibc

>   release, that we can then use the bring up the port of at least one distro.

>   I know OpenEmbedded is coming up for RV32I, which would give me a lot more

>   confidence we have an actual working port.

> * Submit the port after the upcoming release in February.

> * Fix both Linux (for 4.21) and our glibc port to use a 64-bit time_t ABI,

>   which should be possible at least for all core kernel functionality.

>

> I know Zong was at Plumbers, maybe you missed the tool chain thing?

>

> Is this OK with everyone?


I support this plan.
Zong Li Dec. 10, 2018, 9:38 a.m. | #5
Palmer Dabbelt <palmer@dabbelt.com> 於 2018年12月9日 週日 上午4:09寫道:
>

> On Fri, 07 Dec 2018 01:51:46 PST (-0800), zongbox@gmail.com wrote:

> > Joseph Myers <joseph@codesourcery.com> 於 2018年12月4日 週二 上午2:04寫道:

> >>

> >> Could you confirm the ABI entries that would be added to

> >> <https://sourceware.org/glibc/wiki/ABIList>?

> >

> > We would need to add the ABI entries as following:

> > 32-bit, soft-float, LE: /lib/ld-linux-riscv32-ilp32.so.1

> > 32-bit, hard-float, LE: /lib/ld-linux-riscv32-ilp32d.so.1

> >

> >> Could you confirm the minimum upstream kernel version that supports 32-bit

> >> RISC-V with the syscall ABI that will remain supported long-term?  Is it

> >> 4.15, or a later version?  (If a later version, arch_minimum_kernel needs

> >> to be set accordingly.)

> >>

> > I had checked with Palmer, and Palmer would confirm this here.

>

> Sorry for the confusion.  A few of us sat down at the toolchain microconference

> at Plumbers and we decided it would be best to wait until the 32-bit Linux port

> is ready to support a 64-bit time_t ABI.  This isn't ready yet and won't be

> ready in time for the glibc freeze.

>

> The options considered were to:

>

> * Submit this port, which matches the current Linux ABI.  This has been stable

>   since 4.15.

> * Try to push all the 64-bit time_t stuff into the next releases, so Linux

>   4.21 (which is not out yet).

> * Wait until after the next glibc release and then submit the port, ideally

>   also against Linux 4.21.

>

> We all decided to wait, as if we submit this now we'll end up with a RV32I

> glibc port that's 32-bit time_t.  We'd then have to go do another 64-bit time_t

> port along with everyone else, thus making this original port obsolete -- we'd

> have to support the 32-bit time_t port forever, which seems like a headache.

>

> The plan we came up with was to instead:

>

> * Review this port as if it was to be submitted, so we can sort out the issues.

> * Produce an out-of-tree 32-bit time_t port, based on the upcoming glibc

>   release, that we can then use the bring up the port of at least one distro.


Where and how could we put the port?

>   I know OpenEmbedded is coming up for RV32I, which would give me a lot more

>   confidence we have an actual working port.

> * Submit the port after the upcoming release in February.

> * Fix both Linux (for 4.21) and our glibc port to use a 64-bit time_t ABI,

>   which should be possible at least for all core kernel functionality.

>

> I know Zong was at Plumbers, maybe you missed the tool chain thing?


Yes, I had watched the video of the topic. I totally agree your point
and suggestion.
I would fix the issues in this version, and then test rv32 port on
Linux 4.21 in the future.
Thanks to Joseph and DJ to pointed out the problems.

> Is this OK with everyone?


That is OK with me.
Alistair Francis Dec. 10, 2018, 5:17 p.m. | #6
On Sat, 2018-12-08 at 12:08 -0800, Palmer Dabbelt wrote:
> On Fri, 07 Dec 2018 01:51:46 PST (-0800), zongbox@gmail.com wrote:

> > Joseph Myers <joseph@codesourcery.com> 於 2018年12月4日 週二 上午2:04寫道:

> > > Could you confirm the ABI entries that would be added to

> > > <https://sourceware.org/glibc/wiki/ABIList>;?

> > 

> > We would need to add the ABI entries as following:

> > 32-bit, soft-float, LE: /lib/ld-linux-riscv32-ilp32.so.1

> > 32-bit, hard-float, LE: /lib/ld-linux-riscv32-ilp32d.so.1

> > 

> > > Could you confirm the minimum upstream kernel version that

> > > supports 32-bit

> > > RISC-V with the syscall ABI that will remain supported long-

> > > term?  Is it

> > > 4.15, or a later version?  (If a later version,

> > > arch_minimum_kernel needs

> > > to be set accordingly.)

> > > 

> > I had checked with Palmer, and Palmer would confirm this here.

> 

> Sorry for the confusion.  A few of us sat down at the toolchain

> microconference 

> at Plumbers and we decided it would be best to wait until the 32-bit

> Linux port 

> is ready to support a 64-bit time_t ABI.  This isn't ready yet and

> won't be 

> ready in time for the glibc freeze.

> 

> The options considered were to:

> 

> * Submit this port, which matches the current Linux ABI.  This has

> been stable 

>   since 4.15.

> * Try to push all the 64-bit time_t stuff into the next releases, so

> Linux 

>   4.21 (which is not out yet).

> * Wait until after the next glibc release and then submit the port,

> ideally 

>   also against Linux 4.21.

> 

> We all decided to wait, as if we submit this now we'll end up with a

> RV32I 

> glibc port that's 32-bit time_t.  We'd then have to go do another 64-

> bit time_t 

> port along with everyone else, thus making this original port

> obsolete -- we'd 

> have to support the 32-bit time_t port forever, which seems like a

> headache.

> 

> The plan we came up with was to instead:

> 

> * Review this port as if it was to be submitted, so we can sort out

> the issues.

> * Produce an out-of-tree 32-bit time_t port, based on the upcoming

> glibc 

>   release, that we can then use the bring up the port of at least one

> distro.  

>   I know OpenEmbedded is coming up for RV32I, which would give me a

> lot more 

>   confidence we have an actual working port.


Yep, OE has a full RV32I port buildling and booting on QEMU.

If you have a branch you would like us to help test let me know and I
can update meta-riscv.

Alistair

> * Submit the port after the upcoming release in February.

> * Fix both Linux (for 4.21) and our glibc port to use a 64-bit time_t

> ABI, 

>   which should be possible at least for all core kernel

> functionality.

> 

> I know Zong was at Plumbers, maybe you missed the tool chain thing?

> 

> Is this OK with everyone?
Palmer Dabbelt Dec. 10, 2018, 5:33 p.m. | #7
On Mon, 10 Dec 2018 01:38:59 PST (-0800), zongbox@gmail.com wrote:
> Palmer Dabbelt <palmer@dabbelt.com> 於 2018年12月9日 週日 上午4:09寫道:

>>

>> On Fri, 07 Dec 2018 01:51:46 PST (-0800), zongbox@gmail.com wrote:

>> > Joseph Myers <joseph@codesourcery.com> 於 2018年12月4日 週二 上午2:04寫道:

>> >>

>> >> Could you confirm the ABI entries that would be added to

>> >> <https://sourceware.org/glibc/wiki/ABIList>?

>> >

>> > We would need to add the ABI entries as following:

>> > 32-bit, soft-float, LE: /lib/ld-linux-riscv32-ilp32.so.1

>> > 32-bit, hard-float, LE: /lib/ld-linux-riscv32-ilp32d.so.1

>> >

>> >> Could you confirm the minimum upstream kernel version that supports 32-bit

>> >> RISC-V with the syscall ABI that will remain supported long-term?  Is it

>> >> 4.15, or a later version?  (If a later version, arch_minimum_kernel needs

>> >> to be set accordingly.)

>> >>

>> > I had checked with Palmer, and Palmer would confirm this here.

>>

>> Sorry for the confusion.  A few of us sat down at the toolchain microconference

>> at Plumbers and we decided it would be best to wait until the 32-bit Linux port

>> is ready to support a 64-bit time_t ABI.  This isn't ready yet and won't be

>> ready in time for the glibc freeze.

>>

>> The options considered were to:

>>

>> * Submit this port, which matches the current Linux ABI.  This has been stable

>>   since 4.15.

>> * Try to push all the 64-bit time_t stuff into the next releases, so Linux

>>   4.21 (which is not out yet).

>> * Wait until after the next glibc release and then submit the port, ideally

>>   also against Linux 4.21.

>>

>> We all decided to wait, as if we submit this now we'll end up with a RV32I

>> glibc port that's 32-bit time_t.  We'd then have to go do another 64-bit time_t

>> port along with everyone else, thus making this original port obsolete -- we'd

>> have to support the 32-bit time_t port forever, which seems like a headache.

>>

>> The plan we came up with was to instead:

>>

>> * Review this port as if it was to be submitted, so we can sort out the issues.

>> * Produce an out-of-tree 32-bit time_t port, based on the upcoming glibc

>>   release, that we can then use the bring up the port of at least one distro.

>

> Where and how could we put the port?


I think it's OK to put it on github.

>

>>   I know OpenEmbedded is coming up for RV32I, which would give me a lot more

>>   confidence we have an actual working port.

>> * Submit the port after the upcoming release in February.

>> * Fix both Linux (for 4.21) and our glibc port to use a 64-bit time_t ABI,

>>   which should be possible at least for all core kernel functionality.

>>

>> I know Zong was at Plumbers, maybe you missed the tool chain thing?

>

> Yes, I had watched the video of the topic. I totally agree your point

> and suggestion.

> I would fix the issues in this version, and then test rv32 port on

> Linux 4.21 in the future.

> Thanks to Joseph and DJ to pointed out the problems.

>

>> Is this OK with everyone?

>

> That is OK with me.


OK, sounds good!
Joseph Myers Dec. 11, 2018, 5:48 p.m. | #8
On Sat, 8 Dec 2018, Palmer Dabbelt wrote:

> * Fix both Linux (for 4.21) and our glibc port to use a 64-bit time_t ABI,

> which should be possible at least for all core kernel functionality.


Note that if you're planning for the glibc port to use only 64-bit time_t 
(like x32) rather than supporting different values of _TIME_BITS, it would 
be best for it also to use only 64-bit off_t etc. - as _TIME_BITS=64 will 
require _FILE_OFFSET_BITS=64, and I don't think we should have a port 
that's the odd one out in supporting 32-bit offsets with 64-bit times.

-- 
Joseph S. Myers
joseph@codesourcery.com
Palmer Dabbelt Dec. 11, 2018, 6:09 p.m. | #9
On Tue, 11 Dec 2018 09:48:07 PST (-0800), joseph@codesourcery.com wrote:
> On Sat, 8 Dec 2018, Palmer Dabbelt wrote:

>

>> * Fix both Linux (for 4.21) and our glibc port to use a 64-bit time_t ABI,

>> which should be possible at least for all core kernel functionality.

>

> Note that if you're planning for the glibc port to use only 64-bit time_t

> (like x32) rather than supporting different values of _TIME_BITS, it would

> be best for it also to use only 64-bit off_t etc. - as _TIME_BITS=64 will

> require _FILE_OFFSET_BITS=64, and I don't think we should have a port

> that's the odd one out in supporting 32-bit offsets with 64-bit times.


Makes sense to me.
Zong Li Dec. 12, 2018, 12:02 p.m. | #10
Palmer Dabbelt <palmer@dabbelt.com> 於 2018年12月12日 週三 上午2:09寫道:
>

> On Tue, 11 Dec 2018 09:48:07 PST (-0800), joseph@codesourcery.com wrote:

> > On Sat, 8 Dec 2018, Palmer Dabbelt wrote:

> >

> >> * Fix both Linux (for 4.21) and our glibc port to use a 64-bit time_t ABI,

> >> which should be possible at least for all core kernel functionality.

> >

> > Note that if you're planning for the glibc port to use only 64-bit time_t

> > (like x32) rather than supporting different values of _TIME_BITS, it would

> > be best for it also to use only 64-bit off_t etc. - as _TIME_BITS=64 will

> > require _FILE_OFFSET_BITS=64, and I don't think we should have a port

> > that's the odd one out in supporting 32-bit offsets with 64-bit times.

>

> Makes sense to me.


I would take this to next version.