Apparent kernel bug with GDB on ppc405

[Matt Mackall <mpm@selenic.com>]

I'm trying to debug a trivial statically-linked hello world program on
a Xilinx PPC 405 and I'm seeing the following behavior:

With direct gdb on target, I can set a breakpoint at main, run, and
the breakpoint is triggered.

With gdbserver and gdb with "target remote localhost:1234", the above
still works.

With gdb on target redirected to a PC and tunneled back
to the target, everything still works.

With gdb on a PC, execution continues past the breakpoint. Comparing
the gdb protocol streams here and and on the previous (working) case
are identical up to the point of hitting the breakpoint (which never
happens in the latter case).

Raising the load on the PC to 4 and running gdb under nice -n 19 makes
things work again. So this begins to look like a kernel cache or
timing bug rather than a problem with the PC tool. It appears that the
breakpoint written to the executable at continue time is not visible
to the CPU at execute time.

My first suspicion was a dcache/icache coherency issue in
copy_to_user_page, so I added flush_dcache_icache_page(page) here to
no avail. On closer inspection, it looks like both icache and dcache
are already being flushed by flush_icache_user_range().

Adding printk(".") (or any printk) in this function here fixes things
(serial console at 115k), while printk("") and udelay(100) do not.
Which still suggests an icache bug..?

Any suggestions?

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."