Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1261055 > unrolled thread

[RFC PATCH v6 00/17] ILP32 for ARM64

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH v6 00/17] ILP32 for ARM64 Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
    [PATCH v6 03/17] arm64: rename COMPAT to AARCH32_EL0 in Kconfig Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
    [PATCH v6 04/17] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
    [PATCH v6 10/17] arm64:ilp32: support core dump generation for ILP32 Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
    [PATCH v6 08/17] arm64:ilp32: share HWCAP between LP64 and ILP32 Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
    [PATCH v6 14/17] aarch64: ilp32: use generic stat64 structure Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
      Re: [PATCH v6 14/17] aarch64: ilp32: use generic stat64 structure Arnd Bergmann <arnd@arndb.de> - 2015-11-05 15:20 +0100
    [PATCH v6 01/17] arm64:ilp32: add documentation on the ILP32 ABI for ARM64 Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
      Re: [PATCH v6 01/17] arm64:ilp32: add documentation on the ILP32 ABI for ARM64 Arnd Bergmann <arnd@arndb.de> - 2015-11-05 15:40 +0100
    [PATCH v6 11/17] ptrace: Allow compat to use the native siginfo Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
      Re: [PATCH v6 11/17] ptrace: Allow compat to use the native siginfo Arnd Bergmann <arnd@arndb.de> - 2015-11-05 15:00 +0100
    [PATCH v6 15/17] arm64:ilp32: use the native siginfo instead of the compat siginfo Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
    [PATCH v6 07/17] arm64:ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64 Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
    [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
      Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-05 15:00 +0100
      Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Andreas Schwab <schwab@suse.de> - 2015-11-11 19:00 +0100
        Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-11 21:50 +0100
          Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Andreas Schwab <schwab@suse.de> - 2015-11-12 00:10 +0100
            Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-12 00:30 +0100
              Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Andreas Schwab <schwab@suse.de> - 2015-11-12 10:00 +0100
                Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-12 10:30 +0100
                  Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Andreas Schwab <schwab@suse.de> - 2015-11-12 10:50 +0100
                    Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-12 14:30 +0100
                      Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Andreas Schwab <schwab@suse.de> - 2015-11-12 14:50 +0100
                        Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-13 16:40 +0100
                          Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Andrew Pinski <pinskia@gmail.com> - 2015-11-13 16:40 +0100
                            Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-13 17:20 +0100
                              Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-15 16:20 +0100
                                Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Joseph Myers <joseph@codesourcery.com> - 2015-11-16 11:20 +0100
    [PATCH v6 17/17] arm64:ilp32: add ARM64_ILP32 to Kconfig Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
    Re: [RFC PATCH v6 00/17] ILP32 for ARM64 Andreas Schwab <schwab@suse.de> - 2015-11-05 12:40 +0100
      Re: [RFC PATCH v6 00/17] ILP32 for ARM64 Andrew Pinski <pinskia@gmail.com> - 2015-11-05 14:50 +0100
        Re: [RFC PATCH v6 00/17] ILP32 for ARM64 Andreas Schwab <schwab@suse.de> - 2015-11-09 11:10 +0100
          Re: [RFC PATCH v6 00/17] ILP32 for ARM64 "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> - 2015-11-11 08:30 +0100
            Re: [RFC PATCH v6 00/17] ILP32 for ARM64 Andreas Schwab <schwab@suse.de> - 2015-11-11 09:50 +0100
        Re: [RFC PATCH v6 00/17] ILP32 for ARM64 Andreas Schwab <schwab@suse.de> - 2015-11-09 14:30 +0100
          Re: [RFC PATCH v6 00/17] ILP32 for ARM64 Arnd Bergmann <arnd@arndb.de> - 2015-11-09 15:30 +0100
            Re: [RFC PATCH v6 00/17] ILP32 for ARM64 Andreas Schwab <schwab@suse.de> - 2015-11-09 15:40 +0100
              Re: [RFC PATCH v6 00/17] ILP32 for ARM64 Arnd Bergmann <arnd@arndb.de> - 2015-11-09 15:40 +0100
                Re: [RFC PATCH v6 00/17] ILP32 for ARM64 pinskia@gmail.com - 2015-11-09 16:10 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1267746 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Thursday 12 November 2015 09:58:43 Andreas Schwab wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > I think either way is fine for the two examples. I think it's clear
> > that we want __NR_llseek as 62 and __NR_mmap2 as 222. Whether those
> > use the compat_sys_llseek/compat_sys_mmap2_wrapper or
> > sys_lseek/sys_mmap entry points is not overly important, we can use
> > whatever is more convenient to glibc: if we can kill off an
> > architecture specific wrapper function in glibc by adding one line
> > to the kernel, that seems worthwhile.
> 
> Currently most off_t-like syscalls need a new glibc wrapper since the
> existing ones are either for 32bit off_t+off64_t (with split off64_t
> syscall arguments) or pure 64bit off_t architectures.  Since ilp32 now
> (mostly) has 32bit off_t, but 64bit off_t-like syscalls neither of them
> fit.

What do you mean with 32-bit off_t? Do you mean that glibc emulates
a 32-bit off_t on top of the 64-bit __kernel_loff_t? That sounds a bit
backwards. I would expect that all new architectures that only have
__kernel_loff_t based syscalls but not __kernel_off_t based ones only
ever use a 64-bit off_t in libc.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1267756 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

Arnd Bergmann <arnd@arndb.de> writes:

> What do you mean with 32-bit off_t?

An ABI with 32-bit off_t, ie. all currently implemented 32-bit ABIs.

> Do you mean that glibc emulates a 32-bit off_t on top of the 64-bit
> __kernel_loff_t?

Glibc is bridging the user-space ABI to the kernel ABI.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1267907 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Thursday 12 November 2015 10:44:55 Andreas Schwab wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > What do you mean with 32-bit off_t?
> 
> An ABI with 32-bit off_t, ie. all currently implemented 32-bit ABIs.
> 
> > Do you mean that glibc emulates a 32-bit off_t on top of the 64-bit
> > __kernel_loff_t?
> 
> Glibc is bridging the user-space ABI to the kernel ABI.

Ok, but why?

The kernel headers for all recent architectures (arc, c6x, h8300,
hexagon, metag, nios2, openrisc, tile and unicore32) deliberately
leave out the __kernel_off_t based system calls to simplify the
ABI in a way that we never have to support a 32-bit off_t
in user space.

Are there programs that require using a 32-bit off_t by default
on 32-bit architectures but not on 64-bit architectures?
Did the previous version of the ilp32 patch set also emulate
this the same way?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1267935 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

Arnd Bergmann <arnd@arndb.de> writes:

> On Thursday 12 November 2015 10:44:55 Andreas Schwab wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>> 
>> > What do you mean with 32-bit off_t?
>> 
>> An ABI with 32-bit off_t, ie. all currently implemented 32-bit ABIs.
>> 
>> > Do you mean that glibc emulates a 32-bit off_t on top of the 64-bit
>> > __kernel_loff_t?
>> 
>> Glibc is bridging the user-space ABI to the kernel ABI.
>
> Ok, but why?

That's how the ABI is defined right now.  I didn't make that up.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1269025 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Thursday 12 November 2015 14:47:18 Andreas Schwab wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > On Thursday 12 November 2015 10:44:55 Andreas Schwab wrote:
> >> Arnd Bergmann <arnd@arndb.de> writes:
> >> 
> >> > What do you mean with 32-bit off_t?
> >> 
> >> An ABI with 32-bit off_t, ie. all currently implemented 32-bit ABIs.
> >> 
> >> > Do you mean that glibc emulates a 32-bit off_t on top of the 64-bit
> >> > __kernel_loff_t?
> >> 
> >> Glibc is bridging the user-space ABI to the kernel ABI.
> >
> > Ok, but why?
> 
> That's how the ABI is defined right now.  I didn't make that up.

Ok, I guess it will remain a mystery then.

Should we perhaps define __ARCH_WANT_SYSCALL_OFF_T for the unistd.h
file then, so we provide both the off_t and the loff_t based syscalls?

That would avoid the extra wrapper in glibc when using a 32-bit
off_t if that is the preferred mode for user space.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1269027 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Fri, Nov 13, 2015 at 7:34 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 12 November 2015 14:47:18 Andreas Schwab wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>>
>> > On Thursday 12 November 2015 10:44:55 Andreas Schwab wrote:
>> >> Arnd Bergmann <arnd@arndb.de> writes:
>> >>
>> >> > What do you mean with 32-bit off_t?
>> >>
>> >> An ABI with 32-bit off_t, ie. all currently implemented 32-bit ABIs.
>> >>
>> >> > Do you mean that glibc emulates a 32-bit off_t on top of the 64-bit
>> >> > __kernel_loff_t?
>> >>
>> >> Glibc is bridging the user-space ABI to the kernel ABI.
>> >
>> > Ok, but why?
>>
>> That's how the ABI is defined right now.  I didn't make that up.
>
> Ok, I guess it will remain a mystery then.

The biggest question is here is how much compatibility do we want with
other 32bit ABIs?
Do we want off_t to be 32bit or 64bit?

>
> Should we perhaps define __ARCH_WANT_SYSCALL_OFF_T for the unistd.h
> file then, so we provide both the off_t and the loff_t based syscalls?

I think that is backwards ...

>
> That would avoid the extra wrapper in glibc when using a 32-bit
> off_t if that is the preferred mode for user space.


Other targets like tilegx does not do that and has a pure 32bit mode.
Only score does that.

Thanks,
Andrew

>
>         Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1269052 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Friday 13 November 2015 07:38:49 Andrew Pinski wrote:
> On Fri, Nov 13, 2015 at 7:34 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 12 November 2015 14:47:18 Andreas Schwab wrote:
> >> Arnd Bergmann <arnd@arndb.de> writes:
> >>
> >> > On Thursday 12 November 2015 10:44:55 Andreas Schwab wrote:
> >> >> Arnd Bergmann <arnd@arndb.de> writes:
> >> >>
> >> >> > What do you mean with 32-bit off_t?
> >> >>
> >> >> An ABI with 32-bit off_t, ie. all currently implemented 32-bit ABIs.
> >> >>
> >> >> > Do you mean that glibc emulates a 32-bit off_t on top of the 64-bit
> >> >> > __kernel_loff_t?
> >> >>
> >> >> Glibc is bridging the user-space ABI to the kernel ABI.
> >> >
> >> > Ok, but why?
> >>
> >> That's how the ABI is defined right now.  I didn't make that up.
> >
> > Ok, I guess it will remain a mystery then.
> 
> The biggest question is here is how much compatibility do we want with
> other 32bit ABIs?
> Do we want off_t to be 32bit or 64bit?

I would much prefer off_t to be defined as __kernel_loff_t unconditionally,
with no support for _FILE_OFFSET_BITS == 32. This is at least what I had
in mind when I wrote the asm-generic/unistd.h header.

We should probably find out what happened for the other glibc ports that
were implemented for the architectures using this. It's possible that
there was a good reason for supporting _FILE_OFFSET_BITS == 32 at the
time, but I can't think of one and maybe it is one that is no longer
valid.

Do you know what x86/x32 does for off_t? Do they also implement both
_FILE_OFFSET_BITS == 32 and _FILE_OFFSET_BITS == 64 on top of the
64-bit __kernel_off_t?

> > Should we perhaps define __ARCH_WANT_SYSCALL_OFF_T for the unistd.h
> > file then, so we provide both the off_t and the loff_t based syscalls?
> 
> I think that is backwards ...
> 
> >
> > That would avoid the extra wrapper in glibc when using a 32-bit
> > off_t if that is the preferred mode for user space.
> 
> 
> Other targets like tilegx does not do that and has a pure 32bit mode.
> Only score does that.

score was unintentional, it was the first port that got done after we
introduced the generic headers, and they said at the time that they
would change their libc to remove the dependency on the legacy syscalls,
but when I tried to remove them later, they had already shipped it
with them enabled. After that, I told people to never enable the
symbols in an upstream port and only use them for porting their libc
internally. We could actually now move all the legacy syscall stuff
to arch/score/include/uapi/asm/unistd.h, to prevent anyone else from
using it any longer, as glibc works fine without them these days.

The __ARCH_WANT_SYSCALL_OFF_T define might be an exception. If the glibc
developers want to keep using 32-bit off_t by default on all new
architecture, we could include those calls again by default.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1269709 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Friday 13 November 2015 17:10:44 Arnd Bergmann wrote:
> On Friday 13 November 2015 07:38:49 Andrew Pinski wrote:
> > On Fri, Nov 13, 2015 at 7:34 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Thursday 12 November 2015 14:47:18 Andreas Schwab wrote:
> > >> Arnd Bergmann <arnd@arndb.de> writes:
> > >>
> > >> > On Thursday 12 November 2015 10:44:55 Andreas Schwab wrote:
> > >> >> Arnd Bergmann <arnd@arndb.de> writes:
> > >> >>
> > >> >> > What do you mean with 32-bit off_t?
> > >> >>
> > >> >> An ABI with 32-bit off_t, ie. all currently implemented 32-bit ABIs.
> > >> >>
> > >> >> > Do you mean that glibc emulates a 32-bit off_t on top of the 64-bit
> > >> >> > __kernel_loff_t?
> > >> >>
> > >> >> Glibc is bridging the user-space ABI to the kernel ABI.
> > >> >
> > >> > Ok, but why?
> > >>
> > >> That's how the ABI is defined right now.  I didn't make that up.
> > >
> > > Ok, I guess it will remain a mystery then.
> > 
> > The biggest question is here is how much compatibility do we want with
> > other 32bit ABIs?
> > Do we want off_t to be 32bit or 64bit?
> 
> I would much prefer off_t to be defined as __kernel_loff_t unconditionally,
> with no support for _FILE_OFFSET_BITS == 32. This is at least what I had
> in mind when I wrote the asm-generic/unistd.h header.
> 
> We should probably find out what happened for the other glibc ports that
> were implemented for the architectures using this. It's possible that
> there was a good reason for supporting _FILE_OFFSET_BITS == 32 at the
> time, but I can't think of one and maybe it is one that is no longer
> valid.
> 
> Do you know what x86/x32 does for off_t? Do they also implement both
> _FILE_OFFSET_BITS == 32 and _FILE_OFFSET_BITS == 64 on top of the
> 64-bit __kernel_off_t?

I just did a little bit of digging through glibc history and found that
Chris Metcalf added the files that are now in
sysdeps/unix/sysv/linux/generic/wordsize-32/ and that provide the
implementation for 32-bit off_t in glibc on top of the 64-bit
__kernel_off_t.

Chris, do you remember what led to that? Do you think we still need
to have 32-bit off_t on all new architectures, or could we move
on to making 64-bit off_t the default when adding a port?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1269968 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Sun, 15 Nov 2015, Chris Metcalf wrote:

> I've added Rich, Paul, Joseph, and Mike to the cc's as they are probably 
> a good subset of libc-alpha to help comment on these issues.  My sense 
> is that right now, it wouldn't be possible to add a 32-bit architecture 
> with a non-32-bit default for _FILE_OFFSET_BITS.  And, obviously, this 
> is why, when I added the tilegx32 APIs to glibc in 2011, I needed to 
> provide _FILE_OFFSET_BITS=32 support.

x32 uses 64-bit off_t only.  That's not a problem; the problems are 
tv_nsec not of type long, a bug we should avoid for all new ports (padding 
on tv_nsec is fine; treating that padding as a significant high part of a 
64-bit value on input to glibc / kernel interfaces isn't), and maybe some 
other types being 64-bit unnecessarily, although as far as I know the 
suggested issues there 
<https://sourceware.org/bugzilla/show_bug.cgi?id=16438> are all 
theoretical.

It's true that we don't have a very clear notion of what "wordsize-64" 
sysdeps directories mean in glibc for cases such as x32.  See 
<https://sourceware.org/bugzilla/show_bug.cgi?id=14116>.

-- 
Joseph S. Myers
joseph@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1261066 — [PATCH v6 17/17] arm64:ilp32: add ARM64_ILP32 to Kconfig

From: Andrew Pinski <apinski@cavium.com>

This patch adds the config option for ILP32.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Signed-off-by: Andrew Pinski <Andrew.Pinski@caviumnetworks.com>
Reviewed-by: David Daney <david.daney@cavium.com>
---
 arch/arm64/Kconfig | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index d1dc605..afbde9c 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -680,7 +680,7 @@ source "fs/Kconfig.binfmt"
 
 config COMPAT
 	def_bool y
-	depends on AARCH32_EL0
+	depends on AARCH32_EL0 || ARM64_ILP32
 	select COMPAT_BINFMT_ELF
 
 config AARCH32_EL0
@@ -702,6 +702,13 @@ config AARCH32_EL0
 
 	  If you want to execute 32-bit userspace applications, say Y.
 
+config ARM64_ILP32
+	bool "Kernel support for ILP32"
+	help
+	  This option enables support for AArch64 ILP32 user space.  ILP32
+	  is an ABI where long and pointers are 32bits but it uses the AARCH64
+	  instruction set.
+
 config SYSVIPC_COMPAT
 	def_bool y
 	depends on AARCH32_EL0 && SYSVIPC
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1263121

Yury Norov <ynorov@caviumnetworks.com> writes:

> v6:
>  - time_t, __kenel_off_t and other types turned to be 32-bit
>    for compatibility reasons (after v5 discussion);

Are the updated glibc patches available somewhere?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1263207

On Thu, Nov 5, 2015 at 7:36 PM, Andreas Schwab <schwab@suse.de> wrote:
> Yury Norov <ynorov@caviumnetworks.com> writes:
>
>> v6:
>>  - time_t, __kenel_off_t and other types turned to be 32-bit
>>    for compatibility reasons (after v5 discussion);
>
> Are the updated glibc patches available somewhere?

Not in an useful form right now but i will try to get them in an
useful form sometime next week.  I am traveling home on Saturday.

Thanks,
Andrew

>
> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1265504

Yury Norov <ynorov@caviumnetworks.com> writes:

> This is what I run:
> https://github.com/norov/glibc/tree/thunderx-ilp32-32time_toff_t

Thanks, rebootstrapping openSUSE Factory now.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1267005

Hi, Andreas

On 2015/11/9 18:01, Andreas Schwab wrote:
> Yury Norov <ynorov@caviumnetworks.com> writes:
>
>> This is what I run:
>> https://github.com/norov/glibc/tree/thunderx-ilp32-32time_toff_t
>
> Thanks, rebootstrapping openSUSE Factory now.
Where could I find them for testing? I could not find them in your
obs[1].

Best regards

Bamvor

[1] https://build.opensuse.org/package/show/home:Andreas_Schwab:XXX
>
> Andreas.
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1267042

"Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> writes:

> Hi, Andreas
>
> On 2015/11/9 18:01, Andreas Schwab wrote:
>> Yury Norov <ynorov@caviumnetworks.com> writes:
>>
>>> This is what I run:
>>> https://github.com/norov/glibc/tree/thunderx-ilp32-32time_toff_t
>>
>> Thanks, rebootstrapping openSUSE Factory now.
> Where could I find them for testing? I could not find them in your
> obs[1].

It's built in a separate OBS instance, so it's not available publicly
yet.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1265655

Yury Norov <ynorov@caviumnetworks.com> writes:

> This is what I run:
> https://github.com/norov/glibc/tree/thunderx-ilp32-32time_toff_t

That doesn't work for me:

../sysdeps/unix/sysv/linux/generic/sysdep.h:24:22: error: ‘__NR_llseek’ undeclar
ed (first use in this function)
../sysdeps/unix/sysv/linux/aarch64/sysdep.h:41:32: error: ‘__NR_fcntl64’ undeclared (first use in this function)

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1265712

On Monday 09 November 2015 14:23:59 Andreas Schwab wrote:
> Yury Norov <ynorov@caviumnetworks.com> writes:
> 
> > This is what I run:
> > https://github.com/norov/glibc/tree/thunderx-ilp32-32time_toff_t
> 
> That doesn't work for me:
> 
> ../sysdeps/unix/sysv/linux/generic/sysdep.h:24:22: error: ‘__NR_llseek’ undeclar
> ed (first use in this function)
> ../sysdeps/unix/sysv/linux/aarch64/sysdep.h:41:32: error: ‘__NR_fcntl64’ undeclared (first use in this function)
> 

Did you re-export the kernel headers that you use as the base?

The earlier ABI used 64-bit off_t with 'lseek()' and no loff_t, while this
one does uses loff_t with 'llseek()' etc on the kernel side and does not
provide the off_t based syscalls.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1265726

Arnd Bergmann <arnd@arndb.de> writes:

> On Monday 09 November 2015 14:23:59 Andreas Schwab wrote:
>> Yury Norov <ynorov@caviumnetworks.com> writes:
>> 
>> > This is what I run:
>> > https://github.com/norov/glibc/tree/thunderx-ilp32-32time_toff_t
>> 
>> That doesn't work for me:
>> 
>> ../sysdeps/unix/sysv/linux/generic/sysdep.h:24:22: error: ‘__NR_llseek’ undeclar
>> ed (first use in this function)
>> ../sysdeps/unix/sysv/linux/aarch64/sysdep.h:41:32: error: ‘__NR_fcntl64’ undeclared (first use in this function)
>> 
>
> Did you re-export the kernel headers that you use as the base?

I'm using the patched 4.3 kernel headers.  Why is <asm/bitsperlong.h>
defining __BITS_PER_LONG to 64 unconditionally?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1265728

On Monday 09 November 2015 15:33:51 Andreas Schwab wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > On Monday 09 November 2015 14:23:59 Andreas Schwab wrote:
> >> Yury Norov <ynorov@caviumnetworks.com> writes:
> >> 
> >> > This is what I run:
> >> > https://github.com/norov/glibc/tree/thunderx-ilp32-32time_toff_t
> >> 
> >> That doesn't work for me:
> >> 
> >> ../sysdeps/unix/sysv/linux/generic/sysdep.h:24:22: error: ‘__NR_llseek’ undeclar
> >> ed (first use in this function)
> >> ../sysdeps/unix/sysv/linux/aarch64/sysdep.h:41:32: error: ‘__NR_fcntl64’ undeclared (first use in this function)
> >> 
> >
> > Did you re-export the kernel headers that you use as the base?
> 
> I'm using the patched 4.3 kernel headers.

Ok.

>  Why is <asm/bitsperlong.h> defining __BITS_PER_LONG to 64 unconditionally?

It should not, that is a bug. I don't know how Yury built his glibc,
but it can't work if __BITS_PER_LONG is wrong.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1265755

> On Nov 9, 2015, at 10:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> 
>> On Monday 09 November 2015 15:33:51 Andreas Schwab wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>> 
>>>> On Monday 09 November 2015 14:23:59 Andreas Schwab wrote:
>>>> Yury Norov <ynorov@caviumnetworks.com> writes:
>>>> 
>>>>> This is what I run:
>>>>> https://github.com/norov/glibc/tree/thunderx-ilp32-32time_toff_t
>>>> 
>>>> That doesn't work for me:
>>>> 
>>>> ../sysdeps/unix/sysv/linux/generic/sysdep.h:24:22: error: ‘__NR_llseek’ undeclar
>>>> ed (first use in this function)
>>>> ../sysdeps/unix/sysv/linux/aarch64/sysdep.h:41:32: error: ‘__NR_fcntl64’ undeclared (first use in this function)
>>> 
>>> Did you re-export the kernel headers that you use as the base?
>> 
>> I'm using the patched 4.3 kernel headers.
> 
> Ok.
> 
>> Why is <asm/bitsperlong.h> defining __BITS_PER_LONG to 64 unconditionally?
> 
> It should not, that is a bug. I don't know how Yury built his glibc,
> but it can't work if __BITS_PER_LONG is wrong.


Looks like I had changed the header file manually for building glibc and Yury and myself missed that when  he updated the patches. 


Thanks,
Andrew

> 
>    Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web