Hi Michael,
On 16/07/12 03:10, Michael Eager wrote:
On 07/15/2012 04:54 AM, Geert Uytterhoeven wrote:
On Fri, Jul 13, 2012 at 10:18 PM, Michael Eager <eager@xxxxxxxxxxxx> wrote:
On 07/13/2012 01:06 PM, Geert Uytterhoeven wrote:
On Fri, Jul 13, 2012 at 9:14 PM, Michael Eager <eager@xxxxxxxxxxxx> wrote:
I've tracked down a problem in gdb/gdbserver to ptrace() not
clearing the i/d cache after modifying memory.
To reproduce:
m68k-gcc -g -o cf-gdb-test-no-io cf-gdb-test-no-io.c
scp cf-gdb-test-no-io <target>:/
on target: gdbserver :1234 cf-gdb-test-no-io
m68k-gcc cf-gdb-test-no-io
(gdb) b 8
(gdb) b 10
(gdb) tar rem <target>:1234
(gdb) c
(gdb) c
Program will hit first breakpoint, but not second breakpoint.
It appears that the instruction at the last breakpoint location
is in the icache and does not get flushed when the bp is written.
After applying the attached patch, gdb/gdbserver behavior is correct.
Thanks for your report and patch!
I attached the test program, which I previously forgot.
Does this happen only in 2.6.29, or also in current kernels?
The first hunk of your patch no longer applies, as the affected code is
gone and those cases are now handled purely by the generic code.
I'm working with a client's environment using 2.6.29, so I can't verify
that the same failure occurs in recent kernels. But I don't see anything
in ptrace.c in the latest kernel which would clear the i/d caches when
writing to memory.
It can't be a stock 2.6.29 kernel. There is no ColdFire code in
arch/m68k/ in 2.6.29. My best guess is that you are using a kernel
supplied by Freescale with MMU ColdFire support.
Yeah, even 2.6.29 just called the generic version from the m68k-specific code,
which moved a layer up in more recent kernels (commit
faa47b466935e73251b18b17d51455b06ed65764 ("m68k: use generic code for
ptrace requests") by Andreas).
Anyway, I'd expect the generic code to issue a cache flush/invalidate somewhere
around the road, else it would fail for many more platforms.
I'd assume the same, but I couldn't find where this is happening.
So far I couldn't reproduce this (on 3.0 and 3.5-rc6) on 68040 (both ARAnyM
and real hardware). Hence I'm more inclined to believe this is an issue in the
Coldfire-specific code, cfr. the recent cache issues Greg discovered
(http://www.mail-archive.com/linux-m68k@xxxxxxxxxxxxxxx/msg04929.html).
I'll see if this patch also fixes the problem.
I can't try this myself at the moment on 3.5-rc7 with the cache patch.
My gdb and gdbserver seem to be version mis-matched.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@xxxxxxxxxxxx
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
