Weird __put_user_asm behavior

Weird __put_user_asm behavior

[Frank Cornelis]

Hi,

I already posted this question 2 times on this mailing list under the 
subject 'Help on __put_user_asm' but seems like the mailing software 
doesn't like such subjects (or the person behind it:).
So here it goes: when I patch the macro in include/asm-i386/uaccess.h 
named __put_user_asm using the patch below I cannot 'strace ls' anymore.
The ld.so runtime linker just stops when preparing the program displaying 
a nice message; the same message as '/lib/ld-linux.so.2' generates when 
ran without any parameters.
The kernel messages of __put_user_asm go to: 0xbffffb44; then the program 
stops on the ld.so message. 
But, 'strace'-ing of a static compiled program does the job as expected.
What am I doing wrong?

Thanks in advance,
Frank

--- linux-2.4.17/include/asm-i386/uaccess.h	Sat Dec 22 09:35:17 2001
+++ linux/include/asm-i386/uaccess.h	Mon Dec 24 12:43:22 2001
@@ -194,6 +194,10 @@
  * aliasing issues.
  */
 #define __put_user_asm(x, addr, err, itype, rtype, ltype)	\
+do {								\
+	if (current->ptrace & PT_PTRACED) {			\
+		printk(KERN_DEBUG "__put_user_asm: %#x\n", (unsigned long)(addr)); \
+	}							\
 	__asm__ __volatile__(					\
 		"1:	mov"itype" %"rtype"1,%2\n"		\
 		"2:\n"						\
@@ -206,7 +210,8 @@
 		"	.long 1b,3b\n"				\
 		".previous"					\
 		: "=r"(err)					\
-		: ltype (x), "m"(__m(addr)), "i"(-EFAULT), "0"(err))
+		: ltype (x), "m"(__m(addr)), "i"(-EFAULT), "0"(err)); \
+} while (0)
 
 
 #define __get_user_nocheck(x,ptr,size)				\

Re: Weird __put_user_asm behavior

[Frank Cornelis]

Hi,

> > So here it goes: when I patch the macro in include/asm-i386/uaccess.h
> > named __put_user_asm using the patch below I cannot 'strace ls' anymore.
> > The ld.so runtime linker just stops when preparing the program displaying
> > a nice message; the same message as '/lib/ld-linux.so.2' generates when
> > ran without any parameters.
> > The kernel messages of __put_user_asm go to: 0xbffffb44; then the program
> > stops on the ld.so message.
> > But, 'strace'-ing of a static compiled program does the job as expected.
> > What am I doing wrong?
> 
> > --- linux-2.4.17/include/asm-i386/uaccess.h	Sat Dec 22 09:35:17 2001
> > +++ linux/include/asm-i386/uaccess.h	Mon Dec 24 12:43:22 2001
> > @@ -194,6 +194,10 @@
> >   * aliasing issues.
> >   */
> >  #define __put_user_asm(x, addr, err, itype, rtype, ltype)	\
> > +do {								\
> > +	if (current->ptrace & PT_PTRACED) {			\
> > +		printk(KERN_DEBUG "__put_user_asm: %#x\n", (unsigned long)(addr)); \
> > +	}							\
> >  	__asm__ __volatile__(					\
> 
> This must be clobbering some registers and some users of __put_user_asm
> might not expect that... did you try saving/restoring all regs around this 
> 'if'?

I tried to save/restore the eax register before/after the printk function 
call because this register is the only register on an i386 that a function 
may alter without preserving its previous contents (even when the 
function returns void).
What is weird is that an __asm__ __volatile__("nop") within the 
if-statement works so it's not the if-statement itself that is causing 
the problem, also works is a "push %eax\n\tpop %eax" so again it's not 
the stack that is causing the problem. 
But, when I try to access the (addr) parameter then execve shows the 
ld.so message again. This is very odd because all it does is (in most 
cases because GCC optimizes a lot) pushing a general register containing 
(addr) onto the stack then call the function (I also tried a void func) 
and after the call restore esp.
So, any more advice on this?

Thanks in advance,
Frank.

PS: Yes, I'm a thesis student and I really need this :).

Re: Weird __put_user_asm behavior

[alad]

Frank Cornelis <fcorneli@elis.rug.ac.be> on 12/26/2001 04:12:55 PM

To:   vda <vda@port.imtp.ilyichevsk.odessa.ua>
cc:   linux-kernel@vger.kernel.org (bcc: Amol Lad/HSS)

Subject:  Re: Weird __put_user_asm behavior




Hi,

> > So here it goes: when I patch the macro in include/asm-i386/uaccess.h
> > named __put_user_asm using the patch below I cannot 'strace ls' anymore.
> > The ld.so runtime linker just stops when preparing the program displaying
> > a nice message; the same message as '/lib/ld-linux.so.2' generates when
> > ran without any parameters.
> > The kernel messages of __put_user_asm go to: 0xbffffb44; then the program
> > stops on the ld.so message.
> > But, 'strace'-ing of a static compiled program does the job as expected.
> > What am I doing wrong?
>
> > --- linux-2.4.17/include/asm-i386/uaccess.h    Sat Dec 22 09:35:17 2001
> > +++ linux/include/asm-i386/uaccess.h      Mon Dec 24 12:43:22 2001
> > @@ -194,6 +194,10 @@
> >   * aliasing issues.
> >   */
> >  #define __put_user_asm(x, addr, err, itype, rtype, ltype)    \
> > +do {                                     \
> > +     if (current->ptrace & PT_PTRACED) {                \
> > +          printk(KERN_DEBUG "__put_user_asm: %#x\n", (unsigned
long)(addr)); \
> > +     }                                   \
> >       __asm__ __volatile__(                         \
>
> This must be clobbering some registers and some users of __put_user_asm
> might not expect that... did you try saving/restoring all regs around this
> 'if'?

I tried to save/restore the eax register before/after the printk function
call because this register is the only register on an i386 that a function
may alter without preserving its previous contents (even when the
function returns void).
>>>> This concept is wrong. Function is free to use/modify any register it
likes. Its not only eax.
Don't expect the value of a register (ebx/ecx etc) to remain same across AFTER a
function call.

What is weird is that an __asm__ __volatile__("nop") within the
if-statement works so it's not the if-statement itself that is causing
the problem, also works is a "push %eax\n\tpop %eax" so again it's not
the stack that is causing the problem.
But, when I try to access the (addr) parameter then execve shows the
ld.so message again. This is very odd because all it does is (in most
cases because GCC optimizes a lot) pushing a general register containing
(addr) onto the stack then call the function (I also tried a void func)
and after the call restore esp.
So, any more advice on this?

Thanks in advance,
Frank.

PS: Yes, I'm a thesis student and I really need this :).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Weird __put_user_asm behavior

[Manfred Spraul]

The old code evaluates addr once, your new code evaluates it twice.
Have you tried an inline function instead of a macro?
linux/fs/binfmt_elf.c contains a few lines that probably break if 'addr' is evaluated twice:
<<<<<<<
        argv = (elf_caddr_t *) sp;
        if (!ibcs) {
                __put_user((elf_addr_t)(unsigned long) envp,--sp);
                __put_user((elf_addr_t)(unsigned long) argv,--sp);
        }
<<<<<<<<<

--
    Manfred

Re: Weird __put_user_asm behavior

[Frank Cornelis]

Hey,

> The old code evaluates addr once, your new code evaluates it twice.
> Have you tried an inline function instead of a macro?
> linux/fs/binfmt_elf.c contains a few lines that probably break if 'addr' 
> is evaluated twice:
> <<<<<<<
>         argv = (elf_caddr_t *) sp;
>         if (!ibcs) {
>                 __put_user((elf_addr_t)(unsigned long) envp,--sp);
>                 __put_user((elf_addr_t)(unsigned long) argv,--sp);
>         }
> <<<<<<<<<

Double evaluation of the (addr) expression seems to be my problem, not 
register clobbering as I first thought. Although all the macro's that are 
using __put_user_asm also use
	__typeof__(*(addr)) *__their_local_addr = (addr);
	// further use __their_local_addr ...
one apparently needs to repeat this 'localization' of (addr) in order to 
have only one evaluation of (addr) at the end.
I always found the macro paragraph in my first C book -'A Book on C'- a 
little too short :).

Anyway, thanks to all for the help.

Frank.