Subject: Re: more MIPS memcpy bugs...
To: Garrett D'Amore <email@example.com>
From: Simon Burge <firstname.lastname@example.org>
Date: 05/18/2006 21:45:45
Garrett D'Amore wrote:
> I think even on gcc 3.x MIPS32 memcpy is probably busted.
> I've got definite reports of breakage in certain application code
> implicating memcpy and gcc 3.
Please supply a test case if you can.
> I have also verified that the following code in ath_attach() breaks
> printf("sc_debug (%x) in attach is %x\n",
> (uint32_t)&sc->sc_debug, sc->sc_debug);
> memcpy(ifp->if_xname, sc->sc_dev.dv_xname, IFNAMSIZ);
> ah = ath_hal_attach(devid, sc, sc->sc_st, ATH_BUSHANDLE2HAL(sc->sc_sh),
> What happens is that at the point the printf is done, sc_debug contains
> a real value (0x6000 in this case). The cpu_Debugger() call was
> something I added to set a watch point. So I set a watchpoint on the
> address of sc->sc_debug, and get a trap in the inlined assembly for
> memcpy(). Here's a snapshot of my debug, including disassembly of the
> generated MIPS code. I have not gone thru the assembly by hand yet to
> try to figure out what it *thinks* its doing, at this point.
So after the memcpy, sc->sc_debug has a different value? I can't tell
from what you've said what is actually breaking. It seems suspicous
that you're getting the trap only 3 instructions after you continue, and
at the first store after you continue.
I don't think I've ever used ddb watchpoints, only hardware watchpoints.
It appears at a glance that if you set a watch point in ddb then the
entire page is marked readonly so any store in the page will trap - see
the pmap_protect call in ddb/db_watch.c:db_set_watchpoints().
> netbsd:ath_attach+0x6c: lw v0,28(s0)
> netbsd:ath_attach+0x70: move a0,s5
> netbsd:ath_attach+0x74: sw v0,20(s4)
What does s4 contain at this point?
Simon Burge <email@example.com>
NetBSD Support and Service: http://www.wasabisystems.com/