On [Tue, 20.03.2007 19:05], Stuart Anderson wrote:
> Now that the dust has settled, I see where the change is probably a
> no-op anyway. A quick little test program indicates that on x86_64,
> l_start will have an offset of 8 wether the structure is packed or not,
> and wether the __pad member is p
On [Tue, 20.03.2007 21:47], Thiemo Seufer wrote:
> Stuart Anderson wrote:
> [snip]
> > --- linux-user/syscall_defs.h.orig 2007-02-23 15:44:47.0 -0500
> > +++ linux-user/syscall_defs.h 2007-02-23 15:44:26.0 -0500
> > @@ -1414,7 +1414,9 @@
> > struct target_eabi_flock64 {
> >
TARGET_F_*64 should be used instead of F_*64, because on 64-bit host systems
F_GETLK == F_GETLK64(same for SETLK and SETLKW), so we cannot determinate if
it's a long lock or not on a target system.
Patch in the attachment.
P.S. Please, review my privious patches, which I have added description
re
On [Tue, 20.03.2007 13:42], Kirill A. Shutemov wrote:
> Yep. You're right. Fixed patch in the attachment.
>
Patch that fixes dummy bug in the attachment. Sorry.
--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys LLC, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/
On Tue, 20 Mar 2007, Paul Brook wrote:
Now that the dust has settled, I see where the change is probably a
no-op anyway. A quick little test program indicates that on x86_64,
l_start will have an offset of 8 wether the structure is packed or not,
and wether the __pad member is present or not. Th
On Wed, 21 Mar 2007, Kirill A. Shutemov wrote:
Primarily, I also thought that problem is in padding, because, without the
patch F_GETLK, on 32-bit target recognises as F_GETLK64 on 64-bit host.
It's happen because on 64-bit host and 32-bit target F_GETLK == F_GETLK64 ==
TARGET_F_GETLK. So if you
> Now that the dust has settled, I see where the change is probably a
> no-op anyway. A quick little test program indicates that on x86_64,
> l_start will have an offset of 8 wether the structure is packed or not,
> and wether the __pad member is present or not. The unsigned long long is
> always g
On [Tue, 20.03.2007 19:05], Stuart Anderson wrote:
> Now that the dust has settled, I see where the change is probably a
> no-op anyway. A quick little test program indicates that on x86_64,
> l_start will have an offset of 8 wether the structure is packed or not,
> and wether the __pad member is p
On [Tue, 20.03.2007 21:47], Thiemo Seufer wrote:
> Stuart Anderson wrote:
> [snip]
> > --- linux-user/syscall_defs.h.orig 2007-02-23 15:44:47.0 -0500
> > +++ linux-user/syscall_defs.h 2007-02-23 15:44:26.0 -0500
> > @@ -1414,7 +1414,9 @@
> > struct target_eabi_flock64 {
> >
On Tue, 20 Mar 2007, Thiemo Seufer wrote:
Still, this part makes no sense to me since it is in a packed struct.
Can you explain why this works better for you?
It worked better, in that it fixed a problem that let me continue on to
fix other issues. After revisiting fcntl() and coming up with t
Stuart Anderson wrote:
[snip]
> --- linux-user/syscall_defs.h.orig2007-02-23 15:44:47.0 -0500
> +++ linux-user/syscall_defs.h 2007-02-23 15:44:26.0 -0500
> @@ -1414,7 +1414,9 @@
> struct target_eabi_flock64 {
> short l_type;
> short l_whence;
> +#if HOST_LONG_BITS
> struct target_eabi_flock64 {
> short l_type;
> short l_whence;
> +#if HOST_LONG_BITS == 32
> int __pad;
> +#endif
This change is definitely wrong. This is a target structure, and is packed, so
should be independent of the host.
Paul
___
OK, I think I finally have it all sorted out. Sorry if I sounded dense
along the way.. there were multiple variable, which increases the number
of possible combinations quickly.
The patch from Kirill is needed, and makes things better. One thing I
notice with it is that we now handle TARGET_F_GE
On Tue, 20 Mar 2007, Kirill A. Shutemov wrote:
No. Remap is needed:
$ uname -m; echo -e '#include \nF_GETLK64' | cpp | tail -1
x86_64
5
$ uname -m; echo -e '#include \nF_GETLK64' | cpp | tail -1
armv5l
12
Same for F_SETLK64 and F_SETLKW64.
You are right. I had previously printed out the non
On [Tue, 20.03.2007 14:03], Stuart Anderson wrote:
> On Tue, 20 Mar 2007, Kirill A. Shutemov wrote:
>
> >>What are you using as a test app?
> >
> >I got error when runing Debian's apt-get and tried to fix it.
>
> OK, that's what got me started on this one, but I switched to using the
> ltp-kernel
On Tue, 20 Mar 2007, Kirill A. Shutemov wrote:
What are you using as a test app?
I got error when runing Debian's apt-get and tried to fix it.
OK, that's what got me started on this one, but I switched to using the
ltp-kernel-test package for a more comprehensive set of tests once I got
past
On [Tue, 20.03.2007 12:53], Stuart Anderson wrote:
> On Tue, 20 Mar 2007, Kirill A. Shutemov wrote:
>
> >>Kiril,
> >>What 32 bit host and 64 bit host are you using? I'm working on
> >>arm on x86_64, and I'm starting to think that perhaps all of the different
> >>parts of the fix are needed to
On Tue, 20 Mar 2007, Kirill A. Shutemov wrote:
Kiril,
What 32 bit host and 64 bit host are you using? I'm working on
arm on x86_64, and I'm starting to think that perhaps all of the different
parts of the fix are needed to ensure it works correctly on all target/host
combinations.
I'm
On [Tue, 20.03.2007 09:55], Stuart Anderson wrote:
>
> On Tue, 20 Mar 2007, Kirill A. Shutemov wrote:
>
> >Yep. You're right. Fixed patch in the attachment.
>
> Kiril,
> What 32 bit host and 64 bit host are you using? I'm working on
> arm on x86_64, and I'm starting to think that perhaps a
Yep. You're right. Fixed patch in the attachment.
On [Mon, 19.03.2007 17:12], Thiemo Seufer wrote:
> Kirill A. Shutemov wrote:
> > TARGET_F_*64 should be used instead of F_*64, because on 64-bit host
> > systems F_GETLK == F_GETLK64(same for SETLK and SETLKW), so we cannot
> > determinate if it's
On Mon, 19 Mar 2007, Stuart Anderson wrote:
My initial fix was before I started using LTP, and just took care of a
single case that was holding me up. Now I have run the fcntl tests in
LTP on ARM (both oABI and EABI) and there are a lot of failures indicating
that there is a lot more work to be
My initial fix was before I started using LTP, and just took care of a
single case that was holding me up. Now I have run the fcntl tests in
LTP on ARM (both oABI and EABI) and there are a lot of failures indicating
that there is a lot more work to be done yet on fcntl().
I'll take a look into i
Kirill A. Shutemov wrote:
> TARGET_F_*64 should be used instead of F_*64, because on 64-bit host
> systems F_GETLK == F_GETLK64(same for SETLK and SETLKW), so we cannot
> determinate if it's a long lock or not on a target 32-bit system.
> Patch in the attachment.
>
> P.S. Please, review my priviou
TARGET_F_*64 should be used instead of F_*64, because on 64-bit host
systems F_GETLK == F_GETLK64(same for SETLK and SETLKW), so we cannot
determinate if it's a long lock or not on a target 32-bit system.
Patch in the attachment.
P.S. Please, review my privious patches, which I have added descript
24 matches
Mail list logo