Thanks, all
In the C64x+ platform, exceptions are supported. I think this may ease
debug, but
I haven't employed this function so far.
Please read the post:
http://e2e.ti.com/forums/p/9462/37270.aspx#37270
Best Regards
Jogging
On Fri, Aug 28, 2009 at 3:00 PM, William C Bonner wrote:
> The other problem that I've had in the past with
stack corruption was
> simply using more stack than my environment had allocated. If the stack
> attempts to grow past the size allocated, things may appear to be working,
> but you are reading and writing to memory that likely is allocated to other
> code or data. There's no memory protection, so there's no instant
warning
> when this happens.
>
> Wim.
>
> On Thu, Aug 27, 2009 at 6:24 PM, Richard Williams
wrote:
>
>> jogging,
>>
>> once the execution path goes out into the weeds, it is very difficult to
>> determine the cause of the problem.
>>
>> The best way I know of is to halt the program, progressively earlier in
>> its'
>> execution and perform a visual analysis of the stack contents.
>> This is easiest if all functions are compiled to use a stack frame.
>> Otherwise, examine the code at the function entrance point for each
>> function and
>> compare that with the values found in the stack and the values found in
>> the .map
>> file to determine who called the function and with what parameters.
>>
>> A stack is usually corrupted from a rather small number of things.
>> --writing past the end of an array
>> --writing to a 'shorter' stack variable using a 'longer'
data item (often
>> cast
>> or passed incorrectly)
>> --writing, using a uninitialized pointer.
>> R. Williams
>>
>> ---------- Original Message -----------
>> From: jogging song >
>> To: Andrew Elder >
>> Cc: Jeff Brower >,
>> Richard Williams
>> >,
c...
>> Sent: Fri, 28 Aug 2009 09:18:14 +0800
>> Subject: Re: [c6x] function list in the call stack viewer windows is not
>> correct
>>
>> > Thanks, all of you. I really appreciate your help.
>> >
>> > I am wandering what will happen if something is wrong with stack. In
>> some
>> > case this is not catastrophic, which only
>> > cause wrong result. In some case this may lead to crash. Maybe a
>> > address pointers to program section wrongly, and followed is memory
>> > write operation. Can this cause crash? or the program will hang at
>> > somewhere and never move on? It seems that BIOS doesn't provide a
>> > mechanism to find the instruction which causes the crash.
>> >
>> > Best Regards
>> > Jogging
>> >
>> > On Thu, Aug 27, 2009 at 10:33 PM, Andrew Elder
>> >wrote:
>> >
>> > >
>> > > You could also look up the stack location in the .map file and then
>> take a
>> > > look at that memory with the emulator. You should be able to see
>> unused
>> > > stack locations.
>> > >
>> > > - Andrew E.
>> > >
>> > > ------------------------------
>> > > *From:* Jeff Brower
>> >
>> > > *To:* Jogging Song >
>> > > *Cc:* c...
>> > > *Sent:* Thursday, August 27, 2009 9:43:07 AM
>> > > *Subject:* Re: [c6x] function list in the call stack viewer windows is
>> not
>> > > correct
>> > >
>> > >
>> > >
>> > > Jogging-
>> > >
>> > > > I suspect the stack too. I try to make the function as simple as
>> > > > possible.
>> > > > I think the layout of the stack is determined at the compile time.
>> The
>> > > > problems
>> > > > occurs at the very beginning of the function. Before the function is
>> > > called,
>> > > > the code
>> > > > is from the demo.
>> > > > How can find the code which leads to the stack corruption? I also
>> refer
>> > > > to the
>> > > > TMS320C64x+ DSP Megamodule to find what except will occur. It seems
>> no
>> > > such
>> > > > internal exceptions exist.
>> > >
>> > > Maybe you already tried this, but did you test by placing the return
>> > > statement at the top of the function, then moving
>> > > it down, line-by-line?
>> > >
>> > > If the function actually uses too much stack, any call to it should
>> cause a
>> > > crash, even if the function returns
>> > > immediately. If instead there is some buggy code in the function, for
>> > > example writes beyond the end of an array,
>> > > incorrect pointer, etc. it may "look like" a stack problem even though
>> your
>> > > stack allocation and memory placement is
>> > > fine.
>> > >
>> > > -Jeff
>> > >
>> > > > On Thu, Aug 27, 2009 at 1:52 AM, Richard Williams
>>
>> > > com >wrote:
>> > > >
>> > > >> jogging,
>> > > >>
>> > > >> looks like the stack is getting corrupted.
>> > > >>
>> > > >> The stack corruption is probably also the reason the program
>> crashes.
>> > > >>
>> > > >> R. WIlliams
>> > > >>
>> > > >>
>> > > >>
>> > > >> ---------- Original Message -----------
>> > > >> From: joggingsong@ gmail.com
>> > > >> To: c6x@yahoogroups. com
>> > > >> Sent: Wed, 26 Aug 2009 04:18:14 -0400
>> > > >> Subject: [c6x] function list in the call stack viewer windows is
>> not
>> > > >> correct
>> > > >>
>> > > >> > Hi,all
>> > > >> > Recently, I observe a strange problem. When I steps into a
>> > > >> > function, function lists in the call stack viewer change and some
>> > > >> > function name disappears and some changes to a string number. I
>> can't
>> > > >> > understand it. In the mixed mode, I trace the instruction flow
>> and
>> > > >> > find the first register saving instruction can result in this
>> after
>> > > >> > function call occurs.
>> > > >> >
>> > > >> > I try to find the reason. I have made some modification to the
>> > > >> > function I step in,then the function lists is correct. In my
>> opinion,
>> > > >> > the modification changes the stack layout and register usage.
>> > > >> >
>> > > >> > Following is the register usage from generated asm file and in
>> this
>> > > >> > case the function list is erroneous.
>> > > >>
>> > > >> ;*********** ********* ********* ********* ********* *********
>> *********
>> > > ********* ****
>> > > >> > ;* FUNCTION NAME: ModPlane *
>> > > >> > ;*
>> > > >> > * ;* Regs Modified : A0,A1,A2,A3, A4,A5,A6, A7,A8,A9, A10,
>> > > >> > A12,B0,B1,B2, B3,B4,* ;* B5,B6,B7,B8, B9,B10,
>> > > >> > SP,A16,A17,A18, A19,A20,A21, * ;* A22,A23,
>> > > >> > A24,A25,A26, A27,A28,A29, A30,A31,B16, B17, * ;*
>> > > >> > B18,B19,B20, B21,B22,B23, B24,B25,B26, B27,B28,B29, * ;*
>> > > >> > B30,B31 * ;* Regs
>> > > >> > Used : A0,A1,A2,A3, A4,A5,A6, A7,A8,A9, A10,A12,B0, B1,B2,B3,
>> B4,*
>> > > >> > ;* B5,B6,B7,B8, B9,B10,SP, A16,A17,A18, A19,A20,
>> > > >> > A21, * ;* A22,A23,A24, A25,A26,A27, A28,A29,
>> > > >> > A30,A31,B16, B17, * ;* B18,B19,B20, B21,B22,
>> > > >> > B23,B24,B25, B26,B27,B28, B29, * ;* B30,B31
>> > > >> > * ;* Local Frame Size : 8
>> > > >> > Args + 232 Auto + 32 Save = 272 byte *
>> > > >>
>> > > >> ;*********** ********* ********* ********* ********* *********
>> *********
>> > > ********* ****
>> > > >> >
>> > > >> > Following is the register usage from generated asm file and in
>> this
>> > > >> > case the function list is correct.
>> > > >>
>> > > >> ;*********** ********* ********* ********* ********* *********
>> *********
>> > > ********* ****
>> > > >> > ;* FUNCTION NAME: ModPlane *
>> > > >> > ;*
>> > > >> > * ;* Regs Modified : A0,A1,A2,A3, A4,A5,A6, A7,A8,A9, B0,B1,
>> > > >> > B2,B3,B4,B5, B6, * ;* B7,B8,B9,SP, A16,A17,
>> > > >> > A18,A19,A20, A21,A22,A23, A24, * ;* A25,A26,
>> > > >> > A27,A28,A29, A30,A31,B16, B17,B18,B19, B20, * ;*
>> > > >> > B21,B22,B23, B24,B25,B26, B27,B28,B29, B30,B31 * ;* Regs Used
>> > > >> > : A0,A1,A2,A3, A4,A5,A6, A7,A8,A9, A10,B0,B1, B2,B3,B4, B5, * ;*
>> > > >> > B6,B7,B8,B9, SP,A16,A17, A18,A19,A20, A21,A22,A23, *
>> > > >> > ;* A24,A25,A26, A27,A28,A29, A30,A31,B16, B17,
>> > > >> > B18,B19, * ;* B20,B21,B22, B23,B24,B25, B26,
>> > > >> > B27,B28,B29, B30,B31 * ;* Local Frame Size : 8 Args + 232 Auto +
>> 4
>> > > >> > Save = 244 byte *
>> > > >> >
>> > > >> ;*********** ********* ********* ********* ********* *********
>> *********
>> > > ********* ****
>> > > >> >
>> > > >> > In my program, sometimes random crash occurs, and I don't
know
>> whether
>> > > >> > this is linked to the problem. But I neede to find the reason.
>> > > >> >
>> > > >> > Best Regards
>> > > >> > Jogging
>> > > >> ------- End of Original Message -------
>> > >
>> > >
>> > >
>> > >
>> ------- End of Original Message -------
>>
>>
>>