Date: Fri, 27 Mar 2009 08:47:01 -0700 (PDT) From: Doug Ambrisko <ambrisko@ambrisko.com> To: Chagin Dmitry <dchagin@freebsd.org> Cc: Doug Ambrisko <ambrisko@freebsd.org>, src-committers@freebsd.org, Doug Ambrisko <ambrisko@ambrisko.com>, John Baldwin <jhb@freebsd.org>, Roman Divacky <rdivacky@freebsd.org>, svn-src-head@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r190445 - in head/sys: amd64/linux32 compat/linprocfs compat/linux conf dev/ipmi modules/ipmi modules/linprocfs Message-ID: <200903271547.n2RFl1qh044116@ambrisko.com> In-Reply-To: <20090327060643.GA1937@dchagin.static.corbina.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Chagin Dmitry writes:
| On Thu, Mar 26, 2009 at 05:08:59PM -0700, Doug Ambrisko wrote:
[snip]
| > Okay, I did some more instrumenting again and found that I was
| > slightly wrong. The mmap that was failing was 0xcf79c000 and not
| > 0xf0000. This probably makes since since the sign bit was set
| > on 0xcf79c000. However, it appear mmap doesn't really do negative
| > seeks. Looking at the freebsd32_mmap the structure it uses for
| > args is:
| > struct freebsd6_freebsd32_mmap_args {
| > char addr_l_[PADL_(caddr_t)]; caddr_t addr; char addr_r_[PADR_(caddr_t)];
| > char len_l_[PADL_(size_t)]; size_t len; char len_r_[PADR_(size_t)];
| > char prot_l_[PADL_(int)]; int prot; char prot_r_[PADR_(int)];
| > char flags_l_[PADL_(int)]; int flags; char flags_r_[PADR_(int)];
| > char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)];
| > char pad_l_[PADL_(int)]; int pad; char pad_r_[PADR_(int)];
| > char poslo_l_[PADL_(u_int32_t)]; u_int32_t poslo; char poslo_r_[PADR_(u_int32_t)];
| > char poshi_l_[PADL_(u_int32_t)]; u_int32_t poshi; char poshi_r_[PADR_(u_int32_t)];
| > };
| > with both the high and the lows being u_int32_t.
| >
| > So I wonder if in the linux32 the structure that is:
| > struct l_mmap_argv {
| > l_uintptr_t addr;
| > l_size_t len;
| > l_int prot;
| > l_int flags;
| > l_int fd;
| > l_off_t pgoff;
| > } __packed;
| > should be uint32_t for pgoff?
|
| yes, you are right. s/uint32_t/l_ulong/ :)
| also remove __packed.
| thnx!
Index: linux.h
===================================================================
RCS file: /usr/local/cvsroot/freebsd/src/sys/amd64/linux32/linux.h,v
retrieving revision 1.24
diff -u -p -r1.24 linux.h
--- linux.h 26 Mar 2009 17:14:22 -0000 1.24
+++ linux.h 27 Mar 2009 15:38:40 -0000
@@ -79,7 +79,7 @@ typedef l_ulong l_ino_t;
typedef l_int l_key_t;
typedef l_longlong l_loff_t;
typedef l_ushort l_mode_t;
-typedef l_ulong l_off_t;
+typedef l_long l_off_t;
typedef l_int l_pid_t;
typedef l_uint l_size_t;
typedef l_long l_suseconds_t;
@@ -179,8 +179,8 @@ struct l_mmap_argv {
l_int prot;
l_int flags;
l_int fd;
- l_off_t pgoff;
-} __packed;
+ l_ulong pgoff;
+};
/*
* stat family of syscalls
Okay, then this is my proposed patch to fix this. This version works
fine for the Linux tool. If people are happy with it then I'll check it
in. I thought that I had greped for usage of l_off_t but missed that seek
was using it :-(
Thanks,
Doug A.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200903271547.n2RFl1qh044116>