Re: [musl] Re: [PATCHv3 00/24] ILP32 support in ARM64

2015-02-16 Thread Arnd Bergmann
On Monday 16 February 2015 12:51:35 Rich Felker wrote: > On Mon, Feb 16, 2015 at 06:20:18PM +0100, Arnd Bergmann wrote: > > > Would it really be that hard to do: > > > > > > if (ILP32_on_64_process) tv_nsec = (int)tv_nsec; > > > > > > or similar? That's all that's needed. > > > > > > > In some

Re: [musl] Re: [PATCHv3 00/24] ILP32 support in ARM64

2015-02-16 Thread Rich Felker
On Mon, Feb 16, 2015 at 06:20:18PM +0100, Arnd Bergmann wrote: > > Would it really be that hard to do: > > > > if (ILP32_on_64_process) tv_nsec = (int)tv_nsec; > > > > or similar? That's all that's needed. > > > > > In some cases, there may also be a measurable performance penalty > > > in i

Re: [musl] Re: [PATCHv3 00/24] ILP32 support in ARM64

2015-02-16 Thread Arnd Bergmann
On Wednesday 11 February 2015 16:37:58 Rich Felker wrote: > On Wed, Feb 11, 2015 at 10:02:55PM +0100, a...@arndb.de wrote: > > Rich Felker hat am 11. Februar 2015 um 21:12 geschrieben: > > > On Wed, Feb 11, 2015 at 08:50:06PM +0100, a...@arndb.de wrote: > > > > > > At least for AArch64 ILP32 we ar

Re: [musl] Re: [PATCHv3 00/24] ILP32 support in ARM64

2015-02-12 Thread Catalin Marinas
On Thu, Feb 12, 2015 at 09:12:34AM +0100, Szabolcs Nagy wrote: > * Szabolcs Nagy [2015-02-11 20:05:37 +0100]: > > (i think this is also a problem if userspace code uses syscall(2) directly, > > libc cannot possibly know where to signextend and the kernel side does not > > do the fixup right now) >

Re: [musl] Re: [PATCHv3 00/24] ILP32 support in ARM64

2015-02-12 Thread Szabolcs Nagy
* Szabolcs Nagy [2015-02-11 20:05:37 +0100]: > > (i think this is also a problem if userspace code uses syscall(2) directly, > libc cannot possibly know where to signextend and the kernel side does not > do the fixup right now) > nobody picked up this issue, is this resolved? ie. if userspace

Re: [musl] Re: [PATCHv3 00/24] ILP32 support in ARM64

2015-02-11 Thread Rich Felker
On Wed, Feb 11, 2015 at 10:02:55PM +0100, a...@arndb.de wrote: > Rich Felker hat am 11. Februar 2015 um 21:12 geschrieben: > > On Wed, Feb 11, 2015 at 08:50:06PM +0100, a...@arndb.de wrote: > > > > > At least for AArch64 ILP32 we are still free to change the user/kernel > > > > > ABI, so we could

Re: [musl] Re: [PATCHv3 00/24] ILP32 support in ARM64

2015-02-11 Thread a...@arndb.de
Sorry about the HTML mail, I'm currently travelling without access to my regular mail client. > "a...@arndb.de" hat am 11. Februar 2015 um 22:02 geschrieben: > > Rich Felker hat am 11. Februar 2015 um 21:12 geschrieben: > > On Wed, Feb 11, 2015 at 08:50:06PM +0100, a...@arndb.de wrote: > >

Re: [musl] Re: [PATCHv3 00/24] ILP32 support in ARM64

2015-02-11 Thread Rich Felker
On Wed, Feb 11, 2015 at 08:50:06PM +0100, a...@arndb.de wrote: > > > At least for AArch64 ILP32 we are still free to change the user/kernel > > > ABI, so we could add wrappers for the affected syscalls to fix this up. > > > > > > > yes, afaik on x32 the 64bit kernel expects 64bit layout, > > arm64

Re: [musl] Re: [PATCHv3 00/24] ILP32 support in ARM64

2015-02-11 Thread a...@arndb.de
> Szabolcs Nagy hat am 11. Februar 2015 um 20:05 geschrieben: > * Catalin Marinas [2015-02-11 17:39:19 +]: > > (adding Marcus) > > > > On Tue, Feb 10, 2015 at 06:13:02PM +, Rich Felker wrote: > > > I don't know if this has been discussed on libc-alpha yet or not, but > > > I think we need

Re: [musl] Re: [PATCHv3 00/24] ILP32 support in ARM64

2015-02-11 Thread H.J. Lu
On Wed, Feb 11, 2015 at 11:05 AM, Szabolcs Nagy wrote: > i know at least one android kernel issue: there is an ioctl for the > alarm device that takes timespec argument > > (i think it's not in the mainline kernel and i guess android does > not care about x32 so it was not an issue so far, but thi

Re: [musl] Re: [PATCHv3 00/24] ILP32 support in ARM64

2015-02-11 Thread Szabolcs Nagy
* Catalin Marinas [2015-02-11 17:39:19 +]: > (adding Marcus) > > On Tue, Feb 10, 2015 at 06:13:02PM +, Rich Felker wrote: > > I don't know if this has been discussed on libc-alpha yet or not, but > > I think we need to open a discussion of how it relates to open glibc > > bug #16437, whic