Alright, so I got tired of trying to figure out if glibc is doing
something wierd or wrong so I downloaded the source for it, and I'm
looking at it now... (for version 2.2.2 which is what we have on FreeBSD's
linux_base-7) and here's what I'm seeing:
pushl %ebp
pushl %ebx
pushl %e
> yeah, I did that already, and have been running with that since yesterday
> :-P
>
> still not working right though... I think it has something to do with that
> nargs thing... I'm checking that out now...
>
Ehh, apparently sy_narg is getting set correctly too:
struct linux_mmap2_args {
Kenneth Culver wrote:
> >
> > Brandon S Allbery KF8NH writes:
> > > On Wed, 2002-04-24 at 10:41, Andrew Gallatin wrote:
> > > > Maybe the argument isn't where you expect it to be, but is there.
> > > > Can you make a test program which calls mmap2 with its 6th arg as
> > > > something unique l
> RCS file: /home/ncvs/src/sys/i386/linux/linux_sysvec.c,v
> retrieving revision 1.99
> diff -u -2 -r1.99 linux_sysvec.c
> --- linux_sysvec.c 4 Apr 2002 17:49:46 - 1.99
> +++ linux_sysvec.c 24 Apr 2002 23:57:23 -
> @@ -711,4 +711,5 @@
> args[3] = tf->tf_esi;
>
> Here's where it happens:
> sys/i386/linux/linux_sysvec.c
>
> static void
> linux_prepsyscall(struct trapframe *tf, int *args, u_int *code, caddr_t *params)
> {
> args[0] = tf->tf_ebx;
> args[1] = tf->tf_ecx;
> args[2] = tf->tf_edx;
> args[3] = tf->tf_esi;
>
Kenneth Culver wrote:
> > I'm actually still not seeing a match between what's in truss, and what's
> > in my printed-out args, but it seems to be working anyway...
> >
> Argh, it's not working again... It was working on an install of ms office,
> but it won't work on some old windows game.. (win
> I'm actually still not seeing a match between what's in truss, and what's
> in my printed-out args, but it seems to be working anyway...
>
Argh, it's not working again... It was working on an install of ms office,
but it won't work on some old windows game.. (winex) and it's still not
setting t
> > > libc sets it before it enters the kernel. Then on kernel entry we save
> > > ebp in the trapframe.
> >
> > So in the case of linux emulation, the glibc that we're using in the
> > linux-ulator isn't setting it properly? I'm using the linux_base-7 port
> > for this, so as far as I can tell,
> > libc sets it before it enters the kernel. Then on kernel entry we save
> > ebp in the trapframe.
>
> So in the case of linux emulation, the glibc that we're using in the
> linux-ulator isn't setting it properly? I'm using the linux_base-7 port
> for this, so as far as I can tell, it should wo
On 24-Apr-2002 Kenneth Culver wrote:
>> libc sets it before it enters the kernel. Then on kernel entry we save
>> ebp in the trapframe.
>
> So in the case of linux emulation, the glibc that we're using in the
> linux-ulator isn't setting it properly? I'm using the linux_base-7 port
> for this,
> libc sets it before it enters the kernel. Then on kernel entry we save
> ebp in the trapframe.
So in the case of linux emulation, the glibc that we're using in the
linux-ulator isn't setting it properly? I'm using the linux_base-7 port
for this, so as far as I can tell, it should work... assum
On 24-Apr-2002 Kenneth Culver wrote:
>>
>> Brandon S Allbery KF8NH writes:
>> > On Wed, 2002-04-24 at 10:41, Andrew Gallatin wrote:
>> > > Maybe the argument isn't where you expect it to be, but is there.
>> > > Can you make a test program which calls mmap2 with its 6th arg as
>> > > somethin
>
> Brandon S Allbery KF8NH writes:
> > On Wed, 2002-04-24 at 10:41, Andrew Gallatin wrote:
> > > Maybe the argument isn't where you expect it to be, but is there.
> > > Can you make a test program which calls mmap2 with its 6th arg as
> > > something unique like 0xdeadbeef? Then print out (i
I tried printing out everything in the trapframe in hex and nothing looke
remotely right.
Ken
On 24 Apr 2002, Brandon S Allbery KF8NH wrote:
> On Wed, 2002-04-24 at 10:41, Andrew Gallatin wrote:
> > Maybe the argument isn't where you expect it to be, but is there.
> > Can you make a test progra
Brandon S Allbery KF8NH writes:
> On Wed, 2002-04-24 at 10:41, Andrew Gallatin wrote:
> > Maybe the argument isn't where you expect it to be, but is there.
> > Can you make a test program which calls mmap2 with its 6th arg as
> > something unique like 0xdeadbeef? Then print out (in hex :) th
On Wed, 2002-04-24 at 10:41, Andrew Gallatin wrote:
> Maybe the argument isn't where you expect it to be, but is there.
> Can you make a test program which calls mmap2 with its 6th arg as
> something unique like 0xdeadbeef? Then print out (in hex :) the trapframe
> from the linux prepsyscall rout
Kenneth Culver writes:
> OK, I THINK I found what calls the actual kernel syscall handler, and
> sets it's args first, but I'm not sure:
>
> from linux_locore.s
>
> NON_GPROF_ENTRY(linux_sigcode)
<...>
> Does anyone who actually knows assembly have any ideas?
This is the linux sigtramp
> Kenneth Culver writes:
> > OK, I found another problem, here it is:
> >
> > static void
> > linux_prepsyscall(struct trapframe *tf, int *args, u_int *code, caddr_t
> > *params)
> > {
> >args[0] = tf->tf_ebx;
> >args[1] = tf->tf_ecx;
> >args[2] = tf->tf_edx;
> >args[3] =
> > > > Basically, linux_mmap2 takes 6 args, and this looks here like only 5 args are
> > > > making it in... I checked this because the sixth argument to linux_mmap2() in
> > > > truss was showing 0x6, but when I printed out that arg from the kernel, it
> > > > was showing 0x0. Am I corre
Kenneth Culver writes:
> > > Basically, linux_mmap2 takes 6 args, and this looks here like only 5 args are
> > > making it in... I checked this because the sixth argument to linux_mmap2() in
> > > truss was showing 0x6, but when I printed out that arg from the kernel, it
> > > was showing
> > Basically, linux_mmap2 takes 6 args, and this looks here like only 5 args are
> > making it in... I checked this because the sixth argument to linux_mmap2() in
> > truss was showing 0x6, but when I printed out that arg from the kernel, it
> > was showing 0x0. Am I correct here?
> >
> > K
Kenneth Culver writes:
> OK, I found another problem, here it is:
>
> static void
> linux_prepsyscall(struct trapframe *tf, int *args, u_int *code, caddr_t
> *params)
> {
> args[0] = tf->tf_ebx;
> args[1] = tf->tf_ecx;
> args[2] = tf->tf_edx;
> args[3] = tf->tf_esi
On Monday 22 April 2002 10:06 am, you wrote:
> Kenneth Culver writes:
> > static inline unsigned long do_mmap(struct file *file, unsigned long
> > addr,
>
> <..>
>
> >ret = do_mmap_pgoff(file, addr, len, prot, flag, offset >>
> > PAGE_SHIFT); out:
> >return ret;
> > }
> >
>
Kenneth Culver wrote:
> > This is too much work.
> >
> > Basically, it just wants to bitch when the offset is not page
> > aligned, and then call the old mmap if it doesn't bitch.
> >
> OK, I think I can do that, thanks for the help. Will anyone be interested in
> patches when/if I get this workin
> Basically, it just wants to bitch when the offset is not page
> aligned, and then call the old mmap if it doesn't bitch.
>
Basically I misunderstood what the linux mmap2 was doing, it recieves an
offset as a number of pages, not as bytes, so by definition it's already
page aligned. All I have to
Kenneth Culver wrote:
> So what it looks like to me is that mmap2 expects an offset that's already
> page-aligned (I'm not sure if this is the right way to say it), where mmap
> doesn't. the FreeBSD code in the linuxulator basically just takes the offset
> that is passed in with the linux mmap, an
On Monday 22 April 2002 06:29 am, you wrote:
> Kenneth Culver wrote:
> > So what it looks like to me is that mmap2 expects an offset that's
> > already page-aligned (I'm not sure if this is the right way to say it),
> > where mmap doesn't. the FreeBSD code in the linuxulator basically just
> > tak
> > AHH, ok I was wondering where PAGE_SHIFT was for FreeBSD. I guess ctob
> > does what I need it to. I think that's probably why it still wasn't
> > working yet... I think it also has to be page aligned before you pass it
> > in though, I have to look at linux's do_mmap_pgoff() (I think that
Kenneth Culver writes:
> > To me, it looks like mmap2 takes an offset that's a page index, rather
> > than a byte position. Since linux passes the offset with a 32-bit
> > long, rather than a 64-bit off_t like we do, they need to do this in
> > order to be able to map offsets larger than 4G
> To me, it looks like mmap2 takes an offset that's a page index, rather
> than a byte position. Since linux passes the offset with a 32-bit
> long, rather than a 64-bit off_t like we do, they need to do this in
> order to be able to map offsets larger than 4GB into a file.
>
> For linux_mmap2,
Hi,
I have recently been trying to implement the linux mmap2 syscall into our
linuxulator, and I have run into a little problem.
I looked at the code that was used to implement the regular linux_mmap
syscall, and I've also looked in the linux kernel at the code that they use
for mmap
31 matches
Mail list logo
