Re: Platform-independent hack in ptrace.c

Re: Platform-independent hack in ptrace.c

[Ralf Baechle]

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

Re: Platform-independent hack in ptrace.c

[Ralf Baechle]

On Fri, May 28, 1999 at 01:19:45PM +0400, Vladimir A. Roganov wrote:

> We implemented it by very interesting reason: old Baget uses special
> VIC register which exists on bus only (!!!) when interrupt is active.
> But interrupt can be deactivated by external reason. In such case
> IRQ handler catch SIGBUS, what crashes current process.
> 
> It was overwritten twice, and it looks debugged hardly :-)
> May be it can help here.
> 
> > The other bug is that memory accesses via ptrace for virtual addresses
> > which are uncached would be executed cached, trouble ahead.
> 
> YES, we obtained such effect.
> To avoid it we just moved to physical address space (high bits are ignored),
> but it is not good in general.
> 
> > Further complexity is added by handling write buffers for the R3000 and
> > virtual coherency for R4000.
>
> Yes, it should be tried to be fixed once for every arch.

That means we need something like read_phys() and write_phys() for all
CPU variants, even board variations.  The functions needs to get passed
an virtual address as well such that it can deal with virtual coherency
on R4000.

Then again R10k does this in hardware, so why bother ;-)

  Ralf