On 2016/3/29 21:27, Arnd Bergmann wrote:
On Tuesday 29 March 2016 21:21:49 Zhangjian wrote:
Then we could remove the __USE_FILE_OFFSET64 in stat.h and fcnt.h in
aarch64. And truncate and ftruncate is same as truncate64 and
ftruncate64.
I don't know what the glibc developers prefer, but I th
On Tuesday 29 March 2016 21:00:56 Joseph Myers wrote:
> On Tue, 29 Mar 2016, Arnd Bergmann wrote:
>
> > > I think so (along with using wordsize-64 sysdeps directories as far as
> > > possible, like x32 does). But design questions for a glibc port really
> > > belong on libc-alpha to get any sor
On Tue, 29 Mar 2016, Arnd Bergmann wrote:
> > I think so (along with using wordsize-64 sysdeps directories as far as
> > possible, like x32 does). But design questions for a glibc port really
> > belong on libc-alpha to get any sort of community consensus.
>
> I thought the wordsize-64 stuff w
On Tue, 29 Mar 2016, Arnd Bergmann wrote:
> How do we do it then? Should we just define __USE_FILE_OFFSET64
> unconditionally for all new 32-bit architectures and leave the
> code dealing with 32-bit off_t/ino_t in place but unreachable, to
> minimize the differences?
Defining __USE_FILE_OFFSET64
On Tuesday 29 March 2016 20:15:10 Joseph Myers wrote:
> On Tue, 29 Mar 2016, Arnd Bergmann wrote:
>
> > How do we do it then? Should we just define __USE_FILE_OFFSET64
> > unconditionally for all new 32-bit architectures and leave the
> > code dealing with 32-bit off_t/ino_t in place but unreachab
On Tuesday 29 March 2016 15:54:52 Joseph Myers wrote:
> On Tue, 29 Mar 2016, Arnd Bergmann wrote:
>
> > In glibc, I think we need to define fewer entry points, not more.
> > Instead of having both lseek and lseek64, only one of them should
> > be provided, and that should always take a 64-bit offs
On Tue, 29 Mar 2016, Arnd Bergmann wrote:
> In glibc, I think we need to define fewer entry points, not more.
> Instead of having both lseek and lseek64, only one of them should
> be provided, and that should always take a 64-bit offset, calling
> into the kernel with the _llseek syscall entry.
l
On Tuesday 29 March 2016 21:21:49 Zhangjian wrote:
> >>>
> >>> Then we could remove the __USE_FILE_OFFSET64 in stat.h and fcnt.h in
> >>> aarch64. And truncate and ftruncate is same as truncate64 and
> >>> ftruncate64.
> >>
> >> I don't know what the glibc developers prefer, but I think the
> >> re
Hi, Yury
On 2016/3/29 20:01, Yury Norov wrote:
On Tue, Mar 29, 2016 at 12:58:25PM +0200, Arnd Bergmann wrote:
On Saturday 26 March 2016 20:36:43 Zhangjian wrote:
Hi, Arnd
On 2016/3/21 17:43, Arnd Bergmann wrote:
On Monday 21 March 2016 10:07:49 Andreas Schwab wrote:
This patch may fix a few
On Tuesday 29 March 2016 15:01:47 Yury Norov wrote:
> On Tue, Mar 29, 2016 at 12:58:25PM +0200, Arnd Bergmann wrote:
> > On Saturday 26 March 2016 20:36:43 Zhangjian wrote:
> > >
> > > I am a little bit confuse about off_t. In "[PATCH 08/33] 32-bit
> > > ABI: introduce ARCH_32BIT_OFF_T config opti
On Tue, Mar 29, 2016 at 12:58:25PM +0200, Arnd Bergmann wrote:
> On Saturday 26 March 2016 20:36:43 Zhangjian wrote:
> > Hi, Arnd
> >
> > On 2016/3/21 17:43, Arnd Bergmann wrote:
> > > On Monday 21 March 2016 10:07:49 Andreas Schwab wrote:
> > >> This patch may fix a few LTP tests.
> > >>
> > >
>
On Saturday 26 March 2016 20:36:43 Zhangjian wrote:
> Hi, Arnd
>
> On 2016/3/21 17:43, Arnd Bergmann wrote:
> > On Monday 21 March 2016 10:07:49 Andreas Schwab wrote:
> >> This patch may fix a few LTP tests.
> >>
> >
> > Thanks for analyzing.
> >
> >> diff --git a/sysdeps/unix/sysv/linux/aarch64/b
On Sat, Mar 26, 2016 at 09:45:53PM +0800, Zhangjian (Bamvor) wrote:
> Hi, guys
Hi,
>
> Does any body test the bigendian? We found lots of failures in be in
> our arm64 hardware. E.g. the signal issue.
I'm afraid, nobody yet. Thank you for work on it.
>
> IIUC, the signal of struct in ILP32 is
Hi, guys
Does any body test the bigendian? We found lots of failures in be in
our arm64 hardware. E.g. the signal issue.
IIUC, the signal of struct in ILP32 is align with the aarch32. If so,
we need to revert the following patch wrote by Andrew in 2014 which
align the kernel_sigaction of ilp32 t
Hi, Yury
On 2016/3/22 2:40, Yury Norov wrote:
On Mon, Mar 21, 2016 at 10:07:49AM +0100, Andreas Schwab wrote:
[...]
Hi Andreas,
Thank you for your patch. It seems like it fixed a couple of tests.
I applied it to the library branch. Current list of fails is like this:
float_bessel
Hi, Arnd
On 2016/3/21 17:43, Arnd Bergmann wrote:
On Monday 21 March 2016 10:07:49 Andreas Schwab wrote:
This patch may fix a few LTP tests.
Thanks for analyzing.
diff --git a/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h
b/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h
index 3631903..d1010d
On Mon, Mar 21, 2016 at 09:43:12PM +0300, Yury Norov wrote:
> On Mon, Mar 21, 2016 at 07:23:28PM +0800, Zhangjian (Bamvor) wrote:
> > >>So this most probably means that ilp32 code doesn't handle one of cloned
> > >>item properly. I have already discovered a bug where child processes
> > >>used pare
On Mon, Mar 21, 2016 at 10:07:49AM +0100, Andreas Schwab wrote:
> This patch may fix a few LTP tests.
>
> Andreas.
>
> diff --git a/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h
> b/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h
> index 3631903..d1010db 100644
> --- a/sysdeps/unix/sysv/linux/aarch6
On Mon, Mar 21, 2016 at 07:23:28PM +0800, Zhangjian (Bamvor) wrote:
> >>So this most probably means that ilp32 code doesn't handle one of cloned
> >>item properly. I have already discovered a bug where child processes
> >>used parent TLS,
> >It is a kernel bug or glibc bug? Could you please explain
On Monday 21 March 2016 11:52:54 Andreas Schwab wrote:
> Arnd Bergmann writes:
>
> > What exactly do you need to define F_GETLK64 for on LP64?
>
> To override the generic definitions.
Ok, got it. I misread that part as adding definitions for LP64, but it
is correctly removing the definitions f
Hi, Yury
On 2016/3/20 16:12, Zhangjian (Bamvor) wrote:
Hi, Yury
On 2016/3/19 0:46, Yury Norov wrote:
[...]
The minimal test reproducing it is attached. The similar test where
parent forks a child and then kills it, works fine. (Attached too).
I see that in case of pthread, there's much more
Arnd Bergmann writes:
> What exactly do you need to define F_GETLK64 for on LP64?
To override the generic definitions.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On Monday 21 March 2016 10:07:49 Andreas Schwab wrote:
> This patch may fix a few LTP tests.
>
Thanks for analyzing.
> diff --git a/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h
> b/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h
> index 3631903..d1010db 100644
> --- a/sysdeps/unix/sysv/linux/aarch
This patch may fix a few LTP tests.
Andreas.
diff --git a/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h
b/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h
index 3631903..d1010db 100644
--- a/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h
+++ b/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h
@@ -25,18 +25,
Hi, Yury
On 2016/3/19 0:46, Yury Norov wrote:
On Fri, Mar 18, 2016 at 04:55:26PM +0100, Alexander Graf wrote:
On 18.03.16 16:49, Yury Norov wrote:
On Fri, Mar 18, 2016 at 06:28:29PM +0800, Zhangjian (Bamvor) wrote:
For the glibc part, I found that there are 11 patches of ilp32 in top,
but
On Fri, Mar 18, 2016 at 04:55:26PM +0100, Alexander Graf wrote:
>
>
> On 18.03.16 16:49, Yury Norov wrote:
> > On Fri, Mar 18, 2016 at 06:28:29PM +0800, Zhangjian (Bamvor) wrote:
> >>
> >> For the glibc part, I found that there are 11 patches of ilp32 in top,
> >> but the original 28 patches of i
On 18.03.16 16:49, Yury Norov wrote:
> On Fri, Mar 18, 2016 at 06:28:29PM +0800, Zhangjian (Bamvor) wrote:
>>
>> For the glibc part, I found that there are 11 patches of ilp32 in top,
>> but the original 28 patches of ilp32 is not in the top, there are more
>> than 900 patches between them(refere
Hi, Yury
We are trying to test ilp32 in our arm64 board. But we got more
failure compare with you. So, I am wondering if we could align
the test environment with you. The source code we used:
1. glibc: the new-api branch of glibc from
g...@code.huawei.com:gnu/norov_glibc.git.
2. Kernel: r
On Fri, Mar 18, 2016 at 06:28:29PM +0800, Zhangjian (Bamvor) wrote:
> Hi, Yury
>
> We are trying to test ilp32 in our arm64 board. But we got more
> failure compare with you. So, I am wondering if we could align
> the test environment with you. The source code we used:
>
Hi, I mostly use QEMU bu
On Monday 29 February 2016 17:00:29 Andreas Schwab wrote:
> Arnd Bergmann writes:
>
> > 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 yo
Arnd Bergmann writes:
> 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.
The problem really
On Fri, Feb 19, 2016 at 09:23:35AM +0100, Arnd Bergmann wrote:
> I have no idea whether this is good news or bad news ;-)
This is neutral news, I think. V5 had ~25 fails, and aarch32 and lp64 has
~5 fails each. I believe I'll manage to achieve ~25 fails soon. The
rest fails are not clear for me no
On Thu, Feb 25, 2016 at 11:50:31AM +0100, Andreas Schwab wrote:
> Yury Norov writes:
>
> > I have new glibc that follows new ABI:
> > https://github.com/norov/glibc/tree/new-api
>
> sysdeps/unix/sysv/linux/aarch64/ilp32/getdents64.c is wrong, struct
> dirent64 is not the same as struct dirent.
Yury Norov writes:
> I have new glibc that follows new ABI:
> https://github.com/norov/glibc/tree/new-api
sysdeps/unix/sysv/linux/aarch64/ilp32/getdents64.c is wrong, struct
dirent64 is not the same as struct dirent. The file needs to be renamed
to sysdeps/unix/sysv/linux/aarch64/ilp32/getdents
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
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,
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
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,
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 test
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,
>
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
correspon
41 matches
Mail list logo
