Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1337756 > unrolled thread
| Started by | Yury Norov <ynorov@caviumnetworks.com> |
|---|---|
| First post | 2016-02-18 23:40 +0100 |
| Last post | 2016-02-19 15:10 +0100 |
| Articles | 4 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Yury Norov <ynorov@caviumnetworks.com> - 2016-02-18 23:40 +0100
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Arnd Bergmann <arnd@arndb.de> - 2016-02-19 09:30 +0100
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Yury Norov <ynorov@caviumnetworks.com> - 2016-02-19 14:10 +0100
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Arnd Bergmann <arnd@arndb.de> - 2016-02-19 15:10 +0100
| From | Yury Norov <ynorov@caviumnetworks.com> |
|---|---|
| Date | 2016-02-18 23:40 +0100 |
| Subject | Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 |
| Message-ID | <r3FoS-3TL-15@gated-at.bofh.it> |
On Sat, Jan 30, 2016 at 12:15:45PM +0800, Zhangjian (Bamvor) wrote: > Hi, Yury > > On 1:09 2016/1/30, Yury Norov wrote: > >On Fri, Jan 29, 2016 at 05:59:33PM +0800, Zhangjian (Bamvor) wrote: > >>Hi, > >> > >>On 1:22 2016/1/15, Yury Norov wrote: > >>>This is still RFC because we have no glibc yet, that correspnds new ABI > >>>introduced here. And so we cannot run tests. LP64 and AARCH32 tests show > >>>no regression though. > >>Hi, > >> > >>Glad to see this version. I hope I could test it. Where could I find the > >>corresponding glibc? I could not find it in > >>http://github.com/norov/glibc.git. Or is there a plan to do it? > >> > >>Besides compat wrappers discussed in these series, is there any other > >>blockers for upstream? I would suppose everyone is intestested in the > >>result of LTP... > >> > >>Regards > >> > >>Bamvor > >> > > > >Hi, Bamvor, > > > >Just to order all commits, I created new ILP32 branch at [1], that > >based on 4.4 kernel + [2] + [3]. There's no new glibc suitable for > >rfc5. But I started with it, and I hope there will be progress soon. > Cool:) > > > >You cannot run LTP as there are some syscalls that are called during > >dynamic loading that fail, but you can try to build your test statically > >agaginst current glibc, and there's a big chance it will work. > >I have a set of 'hello-worlds' working that way. > Currrently, I got 300+ in ltplite with you glibc[1]. I will try static link > later. > > > >If you have some specific test that you cannot run, you can send it to > >me, and I will take a look on it. > Sure, I am reading the test results. Hope we could fix these failure > together. > > Regards > > Bamvor > > [1] https://github.com/norov/glibc/tree/thunderx-ilp32-32time_toff_t > > > >Yury > > > >[1] https://github.com/norov/linux/tree/rfc5 > >[2] http://permalink.gmane.org/gmane.linux.kernel/2116021 > >[3] http://comments.gmane.org/gmane.linux.kernel/2134747 > > > >>> > >>> v3: https://lkml.org/lkml/2014/9/3/704 > >>> v4: https://lkml.org/lkml/2015/4/13/691 > >>> v5: https://lkml.org/lkml/2015/9/29/911 > >>> Hi Bamvor, everybody, I have new glibc that follows new ABI: https://github.com/norov/glibc/tree/new-api It's very draft and dirty, but you can try it with RFC5. My fail list for ltplite looks like this: pipeio_4 FAIL 11 abort01 FAIL 2 clone02 FAIL 4 kill10 FAIL 2 kill11 FAIL 2 lstat01A FAIL 1 lstat02 FAIL 1 mmap16 FAIL 6 nanosleep03 FAIL 1 nftw01 FAIL 1 nftw6401 FAIL 1 open12 FAIL 2 pathconf01 FAIL 1 pipe07 FAIL 2 profil01 FAIL 11 readdir01 FAIL 1 readlink01A FAIL 1 rename11 FAIL 2 rmdir02 FAIL 2 sigaltstack01 FAIL 1 sigaltstack02 FAIL 1 stat03 FAIL 1 stat04 FAIL 1 stat06 FAIL 1 umount2_01 FAIL 2 umount2_02 FAIL 2 umount2_03 FAIL 2 utime06 FAIL 2 writev01 FAIL 1 mtest06 FAIL 11 rwtest01 FAIL 2 rwtest02 FAIL 2 rwtest03 FAIL 2 rwtest04 FAIL 2 rwtest05 FAIL 2 Float tests are exluded, but also fail. Totally, ~40 of 787 tests fail. Yury
[toc] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-02-19 09:30 +0100 |
| Message-ID | <r3OBQ-2dz-5@gated-at.bofh.it> |
| In reply to | #1337756 |
On Friday 19 February 2016 01:35:06 Yury Norov wrote: > > Hi Bamvor, everybody, > > I have new glibc that follows new ABI: > https://github.com/norov/glibc/tree/new-api Ah, very good! > It's very draft and dirty, but you can try it with RFC5. > My fail list for ltplite looks like this: > pipeio_4 FAIL 11 > abort01 FAIL 2 > clone02 FAIL 4 > kill10 FAIL 2 > kill11 FAIL 2 > lstat01A FAIL 1 > lstat02 FAIL 1 > mmap16 FAIL 6 > nanosleep03 FAIL 1 > nftw01 FAIL 1 > nftw6401 FAIL 1 > open12 FAIL 2 > pathconf01 FAIL 1 > pipe07 FAIL 2 > profil01 FAIL 11 > readdir01 FAIL 1 > readlink01A FAIL 1 > rename11 FAIL 2 > rmdir02 FAIL 2 > sigaltstack01 FAIL 1 > sigaltstack02 FAIL 1 > stat03 FAIL 1 > stat04 FAIL 1 > stat06 FAIL 1 > umount2_01 FAIL 2 > umount2_02 FAIL 2 > umount2_03 FAIL 2 > utime06 FAIL 2 > writev01 FAIL 1 > mtest06 FAIL 11 > rwtest01 FAIL 2 > rwtest02 FAIL 2 > rwtest03 FAIL 2 > rwtest04 FAIL 2 > rwtest05 FAIL 2 I have no idea whether this is good news or bad news ;-) In https://github.com/norov/glibc/commit/351b8728fdb365bd4852ac113601ddf38153fdfc I see that you are passing __IPC_64, I thought we had already resolved that in the kernel. We might need to go back to this. In https://github.com/norov/glibc/commit/5d4290435e428267171ece871539b76e1d079d11 you are defining a struct __kernel_stat64 in the glibc. Is this the expected way to do it? I would have thought you'd get the definition from the kernel headers. Arnd
[toc] | [prev] | [next] | [standalone]
| From | Yury Norov <ynorov@caviumnetworks.com> |
|---|---|
| Date | 2016-02-19 14:10 +0100 |
| Message-ID | <r3SYP-5z8-29@gated-at.bofh.it> |
| In reply to | #1337962 |
On Fri, Feb 19, 2016 at 09:23:35AM +0100, Arnd Bergmann wrote: > On Friday 19 February 2016 01:35:06 Yury Norov wrote: > > > > Hi Bamvor, everybody, > > > > I have new glibc that follows new ABI: > > https://github.com/norov/glibc/tree/new-api > > Ah, very good! > > > It's very draft and dirty, but you can try it with RFC5. > > My fail list for ltplite looks like this: > > pipeio_4 FAIL 11 > > abort01 FAIL 2 > > clone02 FAIL 4 > > kill10 FAIL 2 > > kill11 FAIL 2 > > lstat01A FAIL 1 > > lstat02 FAIL 1 > > mmap16 FAIL 6 > > nanosleep03 FAIL 1 > > nftw01 FAIL 1 > > nftw6401 FAIL 1 > > open12 FAIL 2 > > pathconf01 FAIL 1 > > pipe07 FAIL 2 > > profil01 FAIL 11 > > readdir01 FAIL 1 > > readlink01A FAIL 1 > > rename11 FAIL 2 > > rmdir02 FAIL 2 > > sigaltstack01 FAIL 1 > > sigaltstack02 FAIL 1 > > stat03 FAIL 1 > > stat04 FAIL 1 > > stat06 FAIL 1 > > umount2_01 FAIL 2 > > umount2_02 FAIL 2 > > umount2_03 FAIL 2 > > utime06 FAIL 2 > > writev01 FAIL 1 > > mtest06 FAIL 11 > > rwtest01 FAIL 2 > > rwtest02 FAIL 2 > > rwtest03 FAIL 2 > > rwtest04 FAIL 2 > > rwtest05 FAIL 2 > > I have no idea whether this is good news or bad news ;-) > > In https://github.com/norov/glibc/commit/351b8728fdb365bd4852ac113601ddf38153fdfc > I see that you are passing __IPC_64, I thought we had already resolved > that in the kernel. We might need to go back to this. > I'm still on 4.4 kernel. So I need it. I'll drop __IPC_64 if unneeded on rebase. Usually I rebase on rc5 or rc6. > In https://github.com/norov/glibc/commit/5d4290435e428267171ece871539b76e1d079d11 > you are defining a struct __kernel_stat64 in the glibc. Is this the expected > way to do it? I would have thought you'd get the definition from the kernel > headers. > > Arnd > Almost all ports define its own struct kernel_stat / kernel_stat64. in "kernel_header.h" See mips, spark, alpha, i386... Some also define function xstat_conv or similar. With all that defined, it's expected that one of generic xstat wrappers will work properly. I tried all, and noone got working, so I wrote this hack to make it work somehow. > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-02-19 15:10 +0100 |
| Message-ID | <r3TUS-6ct-7@gated-at.bofh.it> |
| In reply to | #1338178 |
On Friday 19 February 2016 15:59:59 Yury Norov wrote: > On Fri, Feb 19, 2016 at 09:23:35AM +0100, Arnd Bergmann wrote: > > On Friday 19 February 2016 01:35:06 Yury Norov wrote: > > In https://github.com/norov/glibc/commit/5d4290435e428267171ece871539b76e1d079d11 > > you are defining a struct __kernel_stat64 in the glibc. Is this the expected > > way to do it? I would have thought you'd get the definition from the kernel > > headers. > > > > Arnd > > > > Almost all ports define its own struct kernel_stat / kernel_stat64. > in "kernel_header.h" See mips, spark, alpha, i386... Some also define > function xstat_conv or similar. With all that defined, it's expected > that one of generic xstat wrappers will work properly. I tried all, > and noone got working, so I wrote this hack to make it work somehow. I see. I grepped for __kernel_stat64 and couldn't find any other with that name, as the others tend to us slightly different names. I would still think there is something wrong if you need to define your own copy of xstat_conv when the kernel 'struct stat64' is meant to be usable by user space. Shouldn't this work like any other 32-bit architecture now? Arnd
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web