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'm trying to get one that is simple enough.

>   
>> 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.
>   

Yes, sc_debug is zero after the memcpy.   It does seem suspicious.  I've
been wracking my brains out on this one, and the only thing I can think
of is that memcpy itself is busted.

I had considered that maybe the problem was context switches or somesuch
not restoring registers properly, but this happens before context
switching even starts, I believe.

> 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?
>   
I need to walk thru the assembly by hand still, as I indicated.   But at
the point of the trap, s4 contains 0xc011040.   It appears that this is
the address of a function pointer in the ath softc structure.

    -- Garrett

> 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