memcpy_fromfs() failing. Wrong variable offsets

memcpy_fromfs() failing. Wrong variable offsets

[Eduardo Pereira Habkost]

[-- Attachment #1: Type: text/plain, Size: 2825 bytes --]


I was trying to boot ELKS CVS here and it was failing when trying to
run init. I've tracked the bug until I discovered that

memcpy_fromfs() is failing, and it is not copying the right data.

Here is the function, with my debug line:

===============
void memcpy_fromfs(void *daddr, void *saddr, size_t len)
{
    /*@unused@*/ unsigned short int ds = current->t_regs.ds;

#ifndef S_SPLINT_S
#asm
        mov     dx,es
        mov     bx,ds
        mov     es,bx
        mov     ax,[bp-6]       ! source segment (local variable)
        mov     ds,ax
        mov     di,[bp+4]       ! destination address
        mov     si,[bp+6]       ! source address
        mov     cx,[bp+8]       ! number of bytes to copy
        cld
        rep
        movsb
        mov     ds,bx
        mov     es,dx
#endasm
#endif

    debug3("DS: 0x%04x, real: 0x%02x, copied: 0x%02x\n",
                ds, *((unsigned char*)saddr), *((unsigned char*)daddr));
}
====================

Note that, as the DS for the init task, at the time of the error is the
same of the kernel's DS, *((unsigned char*)saddr) showed the right value.

What I got when the kernel tries to run init is:

DS: 0x1dc1, real: 0x64, copied: 0x00

That means: the data wasn't copied.

Looking at the generated assembly file, We get:

==================
! 32 void memcpy_fromfs(daddr,saddr,len)
! Register SI DI used in function verfy_area
verfy_area.off = 0
! 33 # 32 "user.c"
! 32 void *daddr;
export>·_memcpy_fromfs
_memcpy_fromfs:
!BCC_EOS
! 33 # 32 "user.c"
! 32 void *saddr;
!BCC_EOS
! 33 # 32 "user.c"
! 32 size_t len;
!BCC_EOS
! 33 {
! 34       unsigned short int ds = current->t_regs.ds;
push>···bp
mov>····bp,sp
if memcpy_fromfs.off=0
push>···di
push>···si
endif
dec>····sp
dec>····sp
mov>····bx,[_current]
! Debug: eq unsigned short = [bx+6] to unsigned short ds = [S+8-8] (used reg = )
mov>····bx,6[bx]
mov>····-6+memcpy_fromfs.off[bp],bx

[...]

! 53 }
inc>····sp
inc>····sp
if memcpy_fromfs.off=0
pop>····si
pop>····di
endif
pop>····bp
ret
! 54·
! 55 int verified_memcpy_fromfs(daddr,saddr,len)
memcpy_fromfs.off = 4
============

That means: if memcpy_fromfs.off were 0, the function would be ok. The
variable ds is supposed to be in [bp-6], but it is on [bp-2], because
memcpy_fromfs.off is being defined to 4. Probably someday the compiler
generated code in a way that memcpy_fromfs.off was always zero, and the
function assumes that.

Anyway, looking at the code of the compiler, it looks like that
it should know if SI or DI was modified by the function,
because it should save their values on the stack.

I am using dev86-0.16.15 to compile elks.

Someone have reproduced this problem, too? Does anyone had success
booting ELKS CVS?

--
Eduardo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Experimental fix for my memcpy_{to,from}fs problem

[Eduardo Pereira Habkost]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]


The following patch fixes the problem on my system. Probably
with some versions of bcc the patch will break something.

I've added code to save the contents of SI and DI, I don't know if the
callers of these functions assume that SI and DI are touched, but just
in case.

Now the system booted and ran flawlessly.

--- elks/arch/i86/mm/user.c	3 Jun 2002 22:22:58 -0000	1.15
+++ elks/arch/i86/mm/user.c	1 Jun 2004 20:44:51 -0000
@@ -34,10 +34,12 @@
 
 #ifndef S_SPLINT_S
 #asm
+	push	si
+	push	di
 	mov	dx,es
 	mov	bx,ds
 	mov	es,bx
-	mov	ax,[bp-6]	! source segment (local variable)
+	mov	ax,[bp-2]	! source segment (local variable)
 	mov	ds,ax
 	mov	di,[bp+4]	! destination address
 	mov	si,[bp+6]	! source address
@@ -47,8 +49,11 @@
 	movsb
 	mov	ds,bx
 	mov	es,dx
+	pop	di
+	pop	si
 #endasm
 #endif
+
 }
 
 int verified_memcpy_fromfs(void *daddr, void *saddr, size_t len)
@@ -69,8 +74,10 @@
 
 #ifndef S_SPLINT_S
 #asm
+	push	si
+	push	di
 	mov	dx,es
-	mov	ax,[bp-6]	! source segment (local variable)
+	mov	ax,[bp-2]	! source segment (local variable)
 	mov	es,ax
 	mov	di,[bp+4]	! destination address
 	mov	si,[bp+6]	! source address
@@ -79,6 +86,8 @@
 	rep
 	movsb
 	mov	es,dx
+	pop	di
+	pop	si
 #endasm
 #endif
 }

-- 
Eduardo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Experimental fix for my memcpy_{to,from}fs problem

[Eduardo Pereira Habkost]

[-- Attachment #1: Type: text/plain, Size: 2597 bytes --]

Interesting:

The diff between dev86-0.16.0 and 0.16.15 shows:

@@ -664,8 +693,34 @@
        if( main_flag > 2 )
           globl("environ");
     }
+#ifdef I8088
+    regfuse = 0;
+#endif
     lbrace();
     compound();
+#ifdef I8088
+    if (regfuse & callee1mask) {
+        outstr("! Register");
+        if (regfuse & INDREG0 & callee1mask) outstr(" BX");
+        if (regfuse & INDREG1 & callee1mask) outstr(" SI");
+       if (regfuse & INDREG2 & callee1mask) outstr(" DI");
+       outstr(" used in function ");
+       outnstr(funcname);
+       if (optimise && !callersaves) {
+           outstr(funcname);
+           outnstr(".off = 0");
+       }
+    } else
+       if (optimise && !callersaves) {
+           outstr(funcname);
+           outstr(".off = ");
+#ifndef I80386
+           outnhex(4);
+#else
+           outnhex(i386_32?12:4);
+#endif
+       }
+#endif
     clearfunclabels();
 }

This register-saving optmization was added after 0.16.0. The fix is valid,
but probably it will break systems using dev86 <= 0.16.0.

On Tue, Jun 01, 2004 at 07:02:35PM -0300, Eduardo Pereira Habkost wrote:
> 
> The following patch fixes the problem on my system. Probably
> with some versions of bcc the patch will break something.
> 
> I've added code to save the contents of SI and DI, I don't know if the
> callers of these functions assume that SI and DI are touched, but just
> in case.
> 
> Now the system booted and ran flawlessly.
> 
> --- elks/arch/i86/mm/user.c	3 Jun 2002 22:22:58 -0000	1.15
> +++ elks/arch/i86/mm/user.c	1 Jun 2004 20:44:51 -0000
> @@ -34,10 +34,12 @@
>  
>  #ifndef S_SPLINT_S
>  #asm
> +	push	si
> +	push	di
>  	mov	dx,es
>  	mov	bx,ds
>  	mov	es,bx
> -	mov	ax,[bp-6]	! source segment (local variable)
> +	mov	ax,[bp-2]	! source segment (local variable)
>  	mov	ds,ax
>  	mov	di,[bp+4]	! destination address
>  	mov	si,[bp+6]	! source address
> @@ -47,8 +49,11 @@
>  	movsb
>  	mov	ds,bx
>  	mov	es,dx
> +	pop	di
> +	pop	si
>  #endasm
>  #endif
> +
>  }
>  
>  int verified_memcpy_fromfs(void *daddr, void *saddr, size_t len)
> @@ -69,8 +74,10 @@
>  
>  #ifndef S_SPLINT_S
>  #asm
> +	push	si
> +	push	di
>  	mov	dx,es
> -	mov	ax,[bp-6]	! source segment (local variable)
> +	mov	ax,[bp-2]	! source segment (local variable)
>  	mov	es,ax
>  	mov	di,[bp+4]	! destination address
>  	mov	si,[bp+6]	! source address
> @@ -79,6 +86,8 @@
>  	rep
>  	movsb
>  	mov	es,dx
> +	pop	di
> +	pop	si
>  #endasm
>  #endif
>  }
> 
> -- 
> Eduardo



-- 
Eduardo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Experimental fix for my memcpy_{to,from}fs problem

[claudio]

On Tue, 1 Jun 2004, Eduardo Pereira Habkost wrote:

> The following patch fixes the problem on my system. Probably
> with some versions of bcc the patch will break something.
>
> I've added code to save the contents of SI and DI, I don't know if the
> callers of these functions assume that SI and DI are touched, but just
> in case.
>
> Now the system booted and ran flawlessly.

You may need to apply the same fix in strlen_fromfs().

diff -rud e/arch/i86/mm/user.c elks/arch/i86/mm/user.c
--- e/arch/i86/mm/user.c        2004-06-01 22:29:01.000000000 -0300
+++ elks/arch/i86/mm/user.c     2004-06-01 22:27:54.000000000 -0300
@@ -165,8 +165,9 @@

 #ifndef S_SPLINT_S
 #asm
-
-       mov     ax,[bp-6]       ! source segment (local variable)
+       push    di
+       push    si
+       mov     ax,[bp-2]       ! source segment (local variable)
        mov     es,ax
        mov     di,[bp+4]       ! source address
        cld
@@ -177,6 +178,8 @@
        sub     di,[bp+4]       ! calc len +1
        dec     di
        mov     [bp-6],di       ! save in local var ds
+       pop     si
+       pop     di
 #endasm
 #endif

Re: Experimental fix for my memcpy_{to,from}fs problem

[Miguel Bolanos]

Greetings,

On Tue, 2004-06-01 at 16:30, Eduardo Pereira Habkost wrote:
> Interesting:
> 
> The diff between dev86-0.16.0 and 0.16.15 shows:
> 
> @@ -664,8 +693,34 @@
>         if( main_flag > 2 )
>            globl("environ");
>      }
> +#ifdef I8088
> +    regfuse = 0;
> +#endif
>      lbrace();
>      compound();
> +#ifdef I8088
> +    if (regfuse & callee1mask) {
> +        outstr("! Register");
> +        if (regfuse & INDREG0 & callee1mask) outstr(" BX");
> +        if (regfuse & INDREG1 & callee1mask) outstr(" SI");
> +       if (regfuse & INDREG2 & callee1mask) outstr(" DI");
> +       outstr(" used in function ");
> +       outnstr(funcname);
> +       if (optimise && !callersaves) {
> +           outstr(funcname);
> +           outnstr(".off = 0");
> +       }
> +    } else
> +       if (optimise && !callersaves) {
> +           outstr(funcname);
> +           outstr(".off = ");
> +#ifndef I80386
> +           outnhex(4);
> +#else
> +           outnhex(i386_32?12:4);
> +#endif
> +       }
> +#endif
>      clearfunclabels();
>  }
> 
> This register-saving optmization was added after 0.16.0. The fix is valid,
> but probably it will break systems using dev86 <= 0.16.0.
> 

Yes the fix is ok.. but it will break dev86 <= 0.16.0 versions... this
fact makes me hesitate a bit because Bruce does warn that 0.16.15 can
behave a bit unstable.
But we will see.

best wishes

Mike

> On Tue, Jun 01, 2004 at 07:02:35PM -0300, Eduardo Pereira Habkost wrote:
> > 
> > The following patch fixes the problem on my system. Probably
> > with some versions of bcc the patch will break something.
> > 
> > I've added code to save the contents of SI and DI, I don't know if the
> > callers of these functions assume that SI and DI are touched, but just
> > in case.
> > 
> > Now the system booted and ran flawlessly.
> > 
> > --- elks/arch/i86/mm/user.c	3 Jun 2002 22:22:58 -0000	1.15
> > +++ elks/arch/i86/mm/user.c	1 Jun 2004 20:44:51 -0000
> > @@ -34,10 +34,12 @@
> >  
> >  #ifndef S_SPLINT_S
> >  #asm
> > +	push	si
> > +	push	di
> >  	mov	dx,es
> >  	mov	bx,ds
> >  	mov	es,bx
> > -	mov	ax,[bp-6]	! source segment (local variable)
> > +	mov	ax,[bp-2]	! source segment (local variable)
> >  	mov	ds,ax
> >  	mov	di,[bp+4]	! destination address
> >  	mov	si,[bp+6]	! source address
> > @@ -47,8 +49,11 @@
> >  	movsb
> >  	mov	ds,bx
> >  	mov	es,dx
> > +	pop	di
> > +	pop	si
> >  #endasm
> >  #endif
> > +
> >  }
> >  
> >  int verified_memcpy_fromfs(void *daddr, void *saddr, size_t len)
> > @@ -69,8 +74,10 @@
> >  
> >  #ifndef S_SPLINT_S
> >  #asm
> > +	push	si
> > +	push	di
> >  	mov	dx,es
> > -	mov	ax,[bp-6]	! source segment (local variable)
> > +	mov	ax,[bp-2]	! source segment (local variable)
> >  	mov	es,ax
> >  	mov	di,[bp+4]	! destination address
> >  	mov	si,[bp+6]	! source address
> > @@ -79,6 +86,8 @@
> >  	rep
> >  	movsb
> >  	mov	es,dx
> > +	pop	di
> > +	pop	si
> >  #endasm
> >  #endif
> >  }
> > 
> > -- 
> > Eduardo
> 
> 

Re: Experimental fix for my memcpy_{to,from}fs problem

[Miguel Bolanos]

Applied. Thanks.

Mike

On Tue, 2004-06-01 at 16:02, Eduardo Pereira Habkost wrote:
> The following patch fixes the problem on my system. Probably
> with some versions of bcc the patch will break something.
> 
> I've added code to save the contents of SI and DI, I don't know if the
> callers of these functions assume that SI and DI are touched, but just
> in case.
> 
> Now the system booted and ran flawlessly.
> 
> --- elks/arch/i86/mm/user.c	3 Jun 2002 22:22:58 -0000	1.15
> +++ elks/arch/i86/mm/user.c	1 Jun 2004 20:44:51 -0000
> @@ -34,10 +34,12 @@
>  
>  #ifndef S_SPLINT_S
>  #asm
> +	push	si
> +	push	di
>  	mov	dx,es
>  	mov	bx,ds
>  	mov	es,bx
> -	mov	ax,[bp-6]	! source segment (local variable)
> +	mov	ax,[bp-2]	! source segment (local variable)
>  	mov	ds,ax
>  	mov	di,[bp+4]	! destination address
>  	mov	si,[bp+6]	! source address
> @@ -47,8 +49,11 @@
>  	movsb
>  	mov	ds,bx
>  	mov	es,dx
> +	pop	di
> +	pop	si
>  #endasm
>  #endif
> +
>  }
>  
>  int verified_memcpy_fromfs(void *daddr, void *saddr, size_t len)
> @@ -69,8 +74,10 @@
>  
>  #ifndef S_SPLINT_S
>  #asm
> +	push	si
> +	push	di
>  	mov	dx,es
> -	mov	ax,[bp-6]	! source segment (local variable)
> +	mov	ax,[bp-2]	! source segment (local variable)
>  	mov	es,ax
>  	mov	di,[bp+4]	! destination address
>  	mov	si,[bp+6]	! source address
> @@ -79,6 +86,8 @@
>  	rep
>  	movsb
>  	mov	es,dx
> +	pop	di
> +	pop	si
>  #endasm
>  #endif
>  }

Re: Experimental fix for my memcpy_{to,from}fs problem

[Eduardo Pereira Habkost]

[-- Attachment #1: Type: text/plain, Size: 2807 bytes --]

On Tue, Jun 01, 2004 at 08:57:06PM -0600, Miguel Bolanos wrote:
<snip>
> 
> Yes the fix is ok.. but it will break dev86 <= 0.16.0 versions... this
> fact makes me hesitate a bit because Bruce does warn that 0.16.15 can
> behave a bit unstable.
> But we will see.

Yes, and bcc >= 0.16.8 variable offset macros are broken, anyway.

The original code didn't used the offset macros for accessing the
variables. It will work only on:

- dev86 < 0.16.8
- any dev86 version if not using optimization

And it will not work if the bcc variable offset macros bug is fixed,
because the offsets really changed, with the optimized code.

The fix I've sent before really broke systems with dev86 <= 0.16.8.

The following patch against the current CVS code (that already has the
"wrong" fix) change the asm code to access the variables using the
"right way", that is: the variable offset macros.

It will work for:
- dev86 < 0.16.8
- any dev86 version if not using optimization
- dev86 >= 0.16.8 with the previous patch I sent (Fix variable offset macros)
- dev86 with the patch Robert sent

So please apply.

--
Eduardo


--- elks/arch/i86/mm/user.c	2 Jun 2004 03:06:01 -0000	1.16
+++ elks/arch/i86/mm/user.c	2 Jun 2004 15:10:16 -0000
@@ -39,11 +39,11 @@
 	mov	dx,es
 	mov	bx,ds
 	mov	es,bx
-	mov	ax,[bp-2]	! source segment (local variable)
+	mov	ax,[bp+.memcpy_fromfs.ds]	! source segment (local variable)
 	mov	ds,ax
-	mov	di,[bp+4]	! destination address
-	mov	si,[bp+6]	! source address
-	mov	cx,[bp+8]	! number of bytes to copy
+	mov	di,[bp+.memcpy_fromfs.daddr]	! destination address
+	mov	si,[bp+.memcpy_fromfs.saddr]	! source address
+	mov	cx,[bp+.memcpy_fromfs.len]	! number of bytes to copy
 	cld
 	rep
 	movsb
@@ -77,11 +77,11 @@
 	push	si
 	push	di
 	mov	dx,es
-	mov	ax,[bp-2]	! source segment (local variable)
+	mov	ax,[bp+.memcpy_tofs.es]	! source segment (local variable)
 	mov	es,ax
-	mov	di,[bp+4]	! destination address
-	mov	si,[bp+6]	! source address
-	mov	cx,[bp+8]	! number of bytes to copy
+	mov	di,[bp+.memcpy_tofs.daddr]	! destination address
+	mov	si,[bp+.memcpy_tofs.saddr]	! source address
+	mov	cx,[bp+.memcpy_tofs.len]	! number of bytes to copy
 	cld
 	rep
 	movsb
@@ -167,17 +167,17 @@
 #ifndef S_SPLINT_S
 #asm
 
-	mov	ax,[bp-6]	! source segment (local variable)
+	mov	ax,[bp+.strlen_fromfs.ds]	! source segment (local variable)
 	mov	es,ax
-	mov	di,[bp+4]	! source address
+	mov	di,[bp+.strlen_fromfs.saddr]	! source address
 	cld
 	xor	al,al		! search for NULL byte
 	mov	cx,#-1
 	rep
 	scasb
-	sub	di,[bp+4]	! calc len +1
+	sub	di,[bp+.strlen_fromfs.saddr]	! calc len +1
 	dec	di
-	mov	[bp-6],di	! save in local var ds
+	mov	[bp+.strlen_fromfs.ds],di	! save in local var ds
 #endasm
 #endif
 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Experimental fix for my memcpy_{to,from}fs problem

[Miguel Bolanos]

Applied. Thanks

Mike


On Tue, 2004-06-01 at 19:33, claudio@conectiva.com wrote:
> On Tue, 1 Jun 2004, Eduardo Pereira Habkost wrote:
> 
> > The following patch fixes the problem on my system. Probably
> > with some versions of bcc the patch will break something.
> >
> > I've added code to save the contents of SI and DI, I don't know if the
> > callers of these functions assume that SI and DI are touched, but just
> > in case.
> >
> > Now the system booted and ran flawlessly.
> 
> You may need to apply the same fix in strlen_fromfs().
> 
> diff -rud e/arch/i86/mm/user.c elks/arch/i86/mm/user.c
> --- e/arch/i86/mm/user.c        2004-06-01 22:29:01.000000000 -0300
> +++ elks/arch/i86/mm/user.c     2004-06-01 22:27:54.000000000 -0300
> @@ -165,8 +165,9 @@
> 
>  #ifndef S_SPLINT_S
>  #asm
> -
> -       mov     ax,[bp-6]       ! source segment (local variable)
> +       push    di
> +       push    si
> +       mov     ax,[bp-2]       ! source segment (local variable)
>         mov     es,ax
>         mov     di,[bp+4]       ! source address
>         cld
> @@ -177,6 +178,8 @@
>         sub     di,[bp+4]       ! calc len +1
>         dec     di
>         mov     [bp-6],di       ! save in local var ds
> +       pop     si
> +       pop     di
>  #endasm
>  #endif
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Experimental fix for my memcpy_{to,from}fs problem

[Miguel Bolanos]

Applied, but i did some changes on the patch, please read bellow.

On Wed, 2004-06-02 at 10:25, Eduardo Pereira Habkost wrote:
> On Tue, Jun 01, 2004 at 08:57:06PM -0600, Miguel Bolanos wrote:
> <snip>
> > 
> > Yes the fix is ok.. but it will break dev86 <= 0.16.0 versions... this
> > fact makes me hesitate a bit because Bruce does warn that 0.16.15 can
> > behave a bit unstable.
> > But we will see.
> 
> Yes, and bcc >= 0.16.8 variable offset macros are broken, anyway.
> 
> The original code didn't used the offset macros for accessing the
> variables. It will work only on:
> 
> - dev86 < 0.16.8
> - any dev86 version if not using optimization
> 
> And it will not work if the bcc variable offset macros bug is fixed,
> because the offsets really changed, with the optimized code.
> 
> The fix I've sent before really broke systems with dev86 <= 0.16.8.
> 
> The following patch against the current CVS code (that already has the
> "wrong" fix) change the asm code to access the variables using the
> "right way", that is: the variable offset macros.
> 
> It will work for:
> - dev86 < 0.16.8
> - any dev86 version if not using optimization
> - dev86 >= 0.16.8 with the previous patch I sent (Fix variable offset macros)
> - dev86 with the patch Robert sent
> 
> So please apply.
> 
> --
> Eduardo
> 
> 
> --- elks/arch/i86/mm/user.c	2 Jun 2004 03:06:01 -0000	1.16
> +++ elks/arch/i86/mm/user.c	2 Jun 2004 15:10:16 -0000
> @@ -39,11 +39,11 @@
>  	mov	dx,es
>  	mov	bx,ds
>  	mov	es,bx
> -	mov	ax,[bp-2]	! source segment (local variable)
> +	mov	ax,[bp+.memcpy_fromfs.ds]	! source segment (local variable)
>  	mov	ds,ax
> -	mov	di,[bp+4]	! destination address
> -	mov	si,[bp+6]	! source address
> -	mov	cx,[bp+8]	! number of bytes to copy
> +	mov	di,[bp+.memcpy_fromfs.daddr]	! destination address
> +	mov	si,[bp+.memcpy_fromfs.saddr]	! source address
> +	mov	cx,[bp+.memcpy_fromfs.len]	! number of bytes to copy
>  	cld
>  	rep
>  	movsb

This was already applied on a the previous patch

> @@ -77,11 +77,11 @@
>  	push	si
>  	push	di
>  	mov	dx,es
> -	mov	ax,[bp-2]	! source segment (local variable)
> +	mov	ax,[bp+.memcpy_tofs.es]	! source segment (local variable)
>  	mov	es,ax
> -	mov	di,[bp+4]	! destination address
> -	mov	si,[bp+6]	! source address
> -	mov	cx,[bp+8]	! number of bytes to copy
> +	mov	di,[bp+.memcpy_tofs.daddr]	! destination address
> +	mov	si,[bp+.memcpy_tofs.saddr]	! source address
> +	mov	cx,[bp+.memcpy_tofs.len]	! number of bytes to copy
>  	cld
>  	rep
>  	movsb

This was already done as well.

> @@ -167,17 +167,17 @@
>  #ifndef S_SPLINT_S
>  #asm
>  
> -	mov	ax,[bp-6]	! source segment (local variable)
> +	mov	ax,[bp+.strlen_fromfs.ds]	! source segment (local variable)
>  	mov	es,ax
> -	mov	di,[bp+4]	! source address
> +	mov	di,[bp+.strlen_fromfs.saddr]	! source address
>  	cld
>  	xor	al,al		! search for NULL byte
>  	mov	cx,#-1
>  	rep
>  	scasb
> -	sub	di,[bp+4]	! calc len +1
> +	sub	di,[bp+.strlen_fromfs.saddr]	! calc len +1
>  	dec	di
> -	mov	[bp-6],di	! save in local var ds
> +	mov	[bp+.strlen_fromfs.ds],di	! save in local var ds
>  #endasm
>  #endif
>  

This part was applied.

thanks a lot.

-- 
--------------------miguel bolanos, systems administrator, linuxlabs
... ........ ..... ....                 230 peachtree st nw ste 2701
the original linux labs                          atlanta.ga.us 30303
       -since 1995                          http://www.linuxlabs.com
                                office 404.577.7747 fax 404.577.7743
--------------------------------------------------------------------

Re: Experimental fix for my memcpy_{to,from}fs problem

[Eduardo Pereira Habkost]

[-- Attachment #1: Type: text/plain, Size: 2581 bytes --]

Hi, Mike,

On Thu, Jun 03, 2004 at 08:02:18AM -0600, Miguel Bolanos wrote:
> Applied, but i did some changes on the patch, please read bellow.
> 
> > 
> > 
> > --- elks/arch/i86/mm/user.c	2 Jun 2004 03:06:01 -0000	1.16
> > +++ elks/arch/i86/mm/user.c	2 Jun 2004 15:10:16 -0000
> > @@ -39,11 +39,11 @@
> >  	mov	dx,es
> >  	mov	bx,ds
> >  	mov	es,bx
> > -	mov	ax,[bp-2]	! source segment (local variable)
> > +	mov	ax,[bp+.memcpy_fromfs.ds]	! source segment (local variable)
> >  	mov	ds,ax
> > -	mov	di,[bp+4]	! destination address
> > -	mov	si,[bp+6]	! source address
> > -	mov	cx,[bp+8]	! number of bytes to copy
> > +	mov	di,[bp+.memcpy_fromfs.daddr]	! destination address
> > +	mov	si,[bp+.memcpy_fromfs.saddr]	! source address
> > +	mov	cx,[bp+.memcpy_fromfs.len]	! number of bytes to copy
> >  	cld
> >  	rep
> >  	movsb
> 
> This was already applied on a the previous patch

I think I am missing something. What was applied? The code on CVS is not
using .<function>.<variable> to access the function parameters and
variables. This is what is being changed.

> 
> > @@ -77,11 +77,11 @@
> >  	push	si
> >  	push	di
> >  	mov	dx,es
> > -	mov	ax,[bp-2]	! source segment (local variable)
> > +	mov	ax,[bp+.memcpy_tofs.es]	! source segment (local variable)
> >  	mov	es,ax
> > -	mov	di,[bp+4]	! destination address
> > -	mov	si,[bp+6]	! source address
> > -	mov	cx,[bp+8]	! number of bytes to copy
> > +	mov	di,[bp+.memcpy_tofs.daddr]	! destination address
> > +	mov	si,[bp+.memcpy_tofs.saddr]	! source address
> > +	mov	cx,[bp+.memcpy_tofs.len]	! number of bytes to copy
> >  	cld
> >  	rep
> >  	movsb
> 
> This was already done as well.

The CVS don't contain these changes, too. I just 'cvs update'd.

> 
> > @@ -167,17 +167,17 @@
> >  #ifndef S_SPLINT_S
> >  #asm
> >  
> > -	mov	ax,[bp-6]	! source segment (local variable)
> > +	mov	ax,[bp+.strlen_fromfs.ds]	! source segment (local variable)
> >  	mov	es,ax
> > -	mov	di,[bp+4]	! source address
> > +	mov	di,[bp+.strlen_fromfs.saddr]	! source address
> >  	cld
> >  	xor	al,al		! search for NULL byte
> >  	mov	cx,#-1
> >  	rep
> >  	scasb
> > -	sub	di,[bp+4]	! calc len +1
> > +	sub	di,[bp+.strlen_fromfs.saddr]	! calc len +1
> >  	dec	di
> > -	mov	[bp-6],di	! save in local var ds
> > +	mov	[bp+.strlen_fromfs.ds],di	! save in local var ds
> >  #endasm
> >  #endif
> >  
> 
> This part was applied.

The changes are on CVS? I did an 'cvs update', and the last revision of
user.c (1.17) doesn't contain any of these changes.

-- 
Eduardo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Experimental fix for my memcpy_{to,from}fs problem

[Paul Nasrat]

On Thu, Jun 03, 2004 at 11:14:39AM -0300, Eduardo Pereira Habkost wrote:
> Hi, Mike,
> 
> On Thu, Jun 03, 2004 at 08:02:18AM -0600, Miguel Bolanos wrote:
> > Applied, but i did some changes on the patch, please read bellow.
 
> The changes are on CVS? I did an 'cvs update', and the last revision of
> user.c (1.17) doesn't contain any of these changes.

Does sf still lag public anoncvs one day behind?

Paul