Ethan Solomita wrote:

> Simon Burge wrote:
> > 
> >         ...
> >         le0 at ioasic0 offset 0xc0000ioasic0: can't allocate DMA area for LANCE
> >         le0: DMA area not set up
> >         ...
> >         Profiling kernel, textsize=1810624 [80030000..801ea0c0]
> >         trap: address error (load or I-fetch) in kernel mode
> >         status=0xff03, cause=0x10, epc=0x8005d91c, vaddr=0xf
> >         pid=0 cmd=swapper usp=0x0 ksp=0x80294e40
> >         Stopped in swapper at   fork1+0x5c:     lw      v1,16(s1)
> >         db> trace
> >         fork1+5c (1,414,14,0) ra 800565c4 sz 64
> >         main+4a0 (1,414,14,0) ra 80030084 sz 88
> >         User-level: pid 0
> > 
> 	I've tracked this down, since I am trying to get profiling working too.
> I've tracked it down to the _mcount function, but it has been the way it
> is for a real long time now, so I'm confused as to how it ever worked.
> 
> 	In _mcount, defined as an assembler routine in arch/mips/profile.h, it
> saves various registers to 0(sp) through 20(sp). Unfortunately, looking
> at the call into _mcount from various functions, it decrements sp by 8,
> and _mcount doesn't decrement it further. ie. _mcount appears to be
> writing all over the caller's stack!

What was your fix - to subtract another 16 frop sp on entry to _mcount
and add 24 instead of 8 on exit?

> 	I did something much simpler -- no new code, just changed MCOUNT_ENTER
> to s = _splset(0); and MCOUNT_EXIT to _splset(s);  This seems to work
> with my platform -- is it a problem for pmax or others?

_splset is a LEAF function, so it calls MCOUNT.  From what I understand,
we shouldn't profile the profiling support :)

Simon.