2005-04-16 15:20:36 -07:00
/*
* Copyright ( C ) 2002 Jeff Dike ( jdike @ karaya . com )
* Licensed under the GPL
*/
# include <stdio.h>
# include <errno.h>
# include <unistd.h>
# include <linux/stddef.h>
# include "ptrace_user.h"
/* Grr, asm/user.h includes asm/ptrace.h, so has to follow ptrace_user.h */
# include <asm/user.h>
# include "kern_util.h"
# include "sysdep/thread.h"
# include "user.h"
# include "os.h"
[PATCH] uml: clean arch_switch usage
Call arch_switch also in switch_to_skas, even if it's, for now, a no-op for
that case (and mark this in the comment); this will change soon.
Also, arch_switch for TT mode is actually useless when the PT proxy (a
complicate debugging instrumentation for TT mode) is not enabled. In fact, it
only calls update_debugregs, which checks debugregs_seq against seq (to check
if the registers are up-to-date - seq here means a "version number" of the
registers).
If the ptrace proxy is not enabled, debugregs_seq always stays 0 and
update_debugregs will be a no-op. So, optimize this out (the compiler can't
do it).
Also, I've been disappointed by the fact that it would make a lot of sense if,
after calling a successful
update_debugregs(current->thread.arch.debugregs_seq),
current->thread.arch.debugregs_seq were updated with the new debugregs_seq.
But this is not done. Is this a bug or a feature? For all purposes, it seems
a bug (otherwise the whole mechanism does not make sense, which is also a
possibility to check), which causes some performance only problems (not
correctness), since we write_debugregs when not needed.
Also, as suggested by Jeff, remove a redundant enabling of SIGVTALRM,
comprised in the subsequent local_irq_enable(). I'm just a bit dubious if
ordering matters there...
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Acked-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31 02:30:21 -08:00
# include "uml-config.h"
2006-09-25 23:33:00 -07:00
# include "user_util.h"
2005-04-16 15:20:36 -07:00
int ptrace_getregs ( long pid , unsigned long * regs_out )
{
if ( ptrace ( PTRACE_GETREGS , pid , 0 , regs_out ) < 0 )
return - errno ;
return 0 ;
}
int ptrace_setregs ( long pid , unsigned long * regs )
{
if ( ptrace ( PTRACE_SETREGS , pid , 0 , regs ) < 0 )
return - errno ;
return 0 ;
}
int ptrace_getfpregs ( long pid , unsigned long * regs )
{
if ( ptrace ( PTRACE_GETFPREGS , pid , 0 , regs ) < 0 )
return - errno ;
return 0 ;
}
int ptrace_setfpregs ( long pid , unsigned long * regs )
{
if ( ptrace ( PTRACE_SETFPREGS , pid , 0 , regs ) < 0 )
return - errno ;
return 0 ;
}
[PATCH] uml: clean arch_switch usage
Call arch_switch also in switch_to_skas, even if it's, for now, a no-op for
that case (and mark this in the comment); this will change soon.
Also, arch_switch for TT mode is actually useless when the PT proxy (a
complicate debugging instrumentation for TT mode) is not enabled. In fact, it
only calls update_debugregs, which checks debugregs_seq against seq (to check
if the registers are up-to-date - seq here means a "version number" of the
registers).
If the ptrace proxy is not enabled, debugregs_seq always stays 0 and
update_debugregs will be a no-op. So, optimize this out (the compiler can't
do it).
Also, I've been disappointed by the fact that it would make a lot of sense if,
after calling a successful
update_debugregs(current->thread.arch.debugregs_seq),
current->thread.arch.debugregs_seq were updated with the new debugregs_seq.
But this is not done. Is this a bug or a feature? For all purposes, it seems
a bug (otherwise the whole mechanism does not make sense, which is also a
possibility to check), which causes some performance only problems (not
correctness), since we write_debugregs when not needed.
Also, as suggested by Jeff, remove a redundant enabling of SIGVTALRM,
comprised in the subsequent local_irq_enable(). I'm just a bit dubious if
ordering matters there...
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Acked-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31 02:30:21 -08:00
/* All the below stuff is of interest for TT mode only */
2005-04-16 15:20:36 -07:00
static void write_debugregs ( int pid , unsigned long * regs )
{
struct user * dummy ;
int nregs , i ;
dummy = NULL ;
2006-09-25 23:33:00 -07:00
nregs = ARRAY_SIZE ( dummy - > u_debugreg ) ;
2005-04-16 15:20:36 -07:00
for ( i = 0 ; i < nregs ; i + + ) {
if ( ( i = = 4 ) | | ( i = = 5 ) ) continue ;
if ( ptrace ( PTRACE_POKEUSR , pid , & dummy - > u_debugreg [ i ] ,
regs [ i ] ) < 0 )
printk ( " write_debugregs - ptrace failed on "
2006-04-10 22:53:32 -07:00
" register %d, value = 0x%lx, errno = %d \n " , i ,
2005-04-16 15:20:36 -07:00
regs [ i ] , errno ) ;
}
}
static void read_debugregs ( int pid , unsigned long * regs )
{
struct user * dummy ;
int nregs , i ;
dummy = NULL ;
2006-09-25 23:33:00 -07:00
nregs = ARRAY_SIZE ( dummy - > u_debugreg ) ;
2005-04-16 15:20:36 -07:00
for ( i = 0 ; i < nregs ; i + + ) {
regs [ i ] = ptrace ( PTRACE_PEEKUSR , pid ,
& dummy - > u_debugreg [ i ] , 0 ) ;
}
}
/* Accessed only by the tracing thread */
static unsigned long kernel_debugregs [ 8 ] = { [ 0 . . . 7 ] = 0 } ;
void arch_enter_kernel ( void * task , int pid )
{
read_debugregs ( pid , TASK_DEBUGREGS ( task ) ) ;
write_debugregs ( pid , kernel_debugregs ) ;
}
void arch_leave_kernel ( void * task , int pid )
{
read_debugregs ( pid , kernel_debugregs ) ;
write_debugregs ( pid , TASK_DEBUGREGS ( task ) ) ;
}
[PATCH] uml: clean arch_switch usage
Call arch_switch also in switch_to_skas, even if it's, for now, a no-op for
that case (and mark this in the comment); this will change soon.
Also, arch_switch for TT mode is actually useless when the PT proxy (a
complicate debugging instrumentation for TT mode) is not enabled. In fact, it
only calls update_debugregs, which checks debugregs_seq against seq (to check
if the registers are up-to-date - seq here means a "version number" of the
registers).
If the ptrace proxy is not enabled, debugregs_seq always stays 0 and
update_debugregs will be a no-op. So, optimize this out (the compiler can't
do it).
Also, I've been disappointed by the fact that it would make a lot of sense if,
after calling a successful
update_debugregs(current->thread.arch.debugregs_seq),
current->thread.arch.debugregs_seq were updated with the new debugregs_seq.
But this is not done. Is this a bug or a feature? For all purposes, it seems
a bug (otherwise the whole mechanism does not make sense, which is also a
possibility to check), which causes some performance only problems (not
correctness), since we write_debugregs when not needed.
Also, as suggested by Jeff, remove a redundant enabling of SIGVTALRM,
comprised in the subsequent local_irq_enable(). I'm just a bit dubious if
ordering matters there...
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Acked-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31 02:30:21 -08:00
# ifdef UML_CONFIG_PT_PROXY
/* Accessed only by the tracing thread */
static int debugregs_seq ;
/* Only called by the ptrace proxy */
2005-04-16 15:20:36 -07:00
void ptrace_pokeuser ( unsigned long addr , unsigned long data )
{
if ( ( addr < offsetof ( struct user , u_debugreg [ 0 ] ) ) | |
( addr > offsetof ( struct user , u_debugreg [ 7 ] ) ) )
return ;
addr - = offsetof ( struct user , u_debugreg [ 0 ] ) ;
addr = addr > > 2 ;
if ( kernel_debugregs [ addr ] = = data ) return ;
kernel_debugregs [ addr ] = data ;
debugregs_seq + + ;
}
static void update_debugregs_cb ( void * arg )
{
int pid = * ( ( int * ) arg ) ;
write_debugregs ( pid , kernel_debugregs ) ;
}
[PATCH] uml: clean arch_switch usage
Call arch_switch also in switch_to_skas, even if it's, for now, a no-op for
that case (and mark this in the comment); this will change soon.
Also, arch_switch for TT mode is actually useless when the PT proxy (a
complicate debugging instrumentation for TT mode) is not enabled. In fact, it
only calls update_debugregs, which checks debugregs_seq against seq (to check
if the registers are up-to-date - seq here means a "version number" of the
registers).
If the ptrace proxy is not enabled, debugregs_seq always stays 0 and
update_debugregs will be a no-op. So, optimize this out (the compiler can't
do it).
Also, I've been disappointed by the fact that it would make a lot of sense if,
after calling a successful
update_debugregs(current->thread.arch.debugregs_seq),
current->thread.arch.debugregs_seq were updated with the new debugregs_seq.
But this is not done. Is this a bug or a feature? For all purposes, it seems
a bug (otherwise the whole mechanism does not make sense, which is also a
possibility to check), which causes some performance only problems (not
correctness), since we write_debugregs when not needed.
Also, as suggested by Jeff, remove a redundant enabling of SIGVTALRM,
comprised in the subsequent local_irq_enable(). I'm just a bit dubious if
ordering matters there...
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Acked-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31 02:30:21 -08:00
/* Optimized out in its header when not defined */
2005-04-16 15:20:36 -07:00
void update_debugregs ( int seq )
{
int me ;
if ( seq = = debugregs_seq ) return ;
me = os_getpid ( ) ;
initial_thread_cb ( update_debugregs_cb , & me ) ;
}
[PATCH] uml: clean arch_switch usage
Call arch_switch also in switch_to_skas, even if it's, for now, a no-op for
that case (and mark this in the comment); this will change soon.
Also, arch_switch for TT mode is actually useless when the PT proxy (a
complicate debugging instrumentation for TT mode) is not enabled. In fact, it
only calls update_debugregs, which checks debugregs_seq against seq (to check
if the registers are up-to-date - seq here means a "version number" of the
registers).
If the ptrace proxy is not enabled, debugregs_seq always stays 0 and
update_debugregs will be a no-op. So, optimize this out (the compiler can't
do it).
Also, I've been disappointed by the fact that it would make a lot of sense if,
after calling a successful
update_debugregs(current->thread.arch.debugregs_seq),
current->thread.arch.debugregs_seq were updated with the new debugregs_seq.
But this is not done. Is this a bug or a feature? For all purposes, it seems
a bug (otherwise the whole mechanism does not make sense, which is also a
possibility to check), which causes some performance only problems (not
correctness), since we write_debugregs when not needed.
Also, as suggested by Jeff, remove a redundant enabling of SIGVTALRM,
comprised in the subsequent local_irq_enable(). I'm just a bit dubious if
ordering matters there...
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Acked-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31 02:30:21 -08:00
# endif
2005-04-16 15:20:36 -07:00
/*
* Overrides for Emacs so that we follow Linus ' s tabbing style .
* Emacs will notice this stuff at the end of the file and automatically
* adjust the settings for this buffer only . This must remain at the end
* of the file .
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* Local variables :
* c - file - style : " linux "
* End :
*/