Re: Platform-independent hack in ptrace.c

[Ralf Baechle <ralf@uni-koblenz.de>]

On Thu, May 27, 1999 at 04:17:42PM +0400, Vladimir A. Roganov wrote:

> Does anybody know which kind of protection is encoded in ptrace.c:69:
> (function get_long)
> 
> 	/* This is a hack for non-kernel-mapped video buffers and similar */
> 	if (MAP_NR(page) >= MAP_NR(high_memory))
> 		return 0;
> 
> By this reason gdb shows all user-mapped io as zeros.
> 
> Same time, put_long enable to write to such memory !
> So when You enter something like 'set *p = 0xff' gdb'ing program 
> which has p->video_memory, You will see appearing pixels, but 'p *p' 
> prints only zeros.
> 
> Elimination of this check does not destroy something: gdb shows right
> values.
> 
> It looks clean that above problem is not very important, but just
> imagine programmer debugging some application for Linux used to control
> some device on MIPS embedded computer, which mmap'ed to device registers
> and don't understand why they are all clean :-)

Basically I think you're right.  However a correct patch is slightly more
complex and will acount for the fact that KSEG0 through which we route
the access is only 512mb large.  Therefore we might have to install a
temporary mapping and access memory through it, if outside of the 512mb.
The other bug is that memory accesses via ptrace for virtual addresses
which are uncached would be executed cached, trouble ahead.  Further
complexity is added by handling write buffers for the R3000 and
virtual coherency for R4000.

  Ralf