Subject: Re: more MIPS memcpy bugs...
To: Simon Burge <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 05/18/2006 08:38:33
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
>> 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.
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.
> Simon Burge <email@example.com>
> NetBSD Support and Service: http://www.wasabisystems.com/
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191