Okay, I feel *stoopid*.

The problem appears to be that ddb watchpoints in the kernel trigger on
*any* modification to the entire page, not just the given address.  So
the write to an unrelated address was triggering the watchpoint.

Aargh...

And it turns out that the debug problem occurred elsewhere.... :-) 
sc_debug was getting zeroed by the sysctl code.  Grrr....

I apologize for wasting the time of anyone who looked at this.

    -- Garrett

Simon Burge wrote:
> 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/
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191