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
> terribly:
> 
>     printf("sc_debug (%x) in attach is %x\n",
>         (uint32_t)&sc->sc_debug, sc->sc_debug);
>     cpu_Debugger();
> 
>     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.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/