From: SourceForge.net <no...@so...> - 2005-11-08 17:55:37
|
Bugs item #1350513, was opened at 2005-11-07 18:02 Message generated for change (Comment added) made by remarc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1350513&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Run Time Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Possible bug in longjmp() Initial Comment: I believe I have found a bug in the implementation of longjmp(). There appears to be critical section in that code, during which an interrupt can clobber up the stack frame under modification. I have adapted the code by temporarily disabling interrupts. That took care of the spurious lock-ups in my app. int my_longjmp (unsigned char *bp, int rv) { unsigned char lsp; bit save_EA; save_EA = EA; EA = 0; // start of critical section lsp = *(bp+2); *((unsigned char data *) lsp) = *bp++; *((unsigned char data *) lsp - 1) = *bp; SP = lsp; // end of critical section EA = save_EA; return rv; } Regards, Jim Cramer ji...@ji... ---------------------------------------------------------------------- Comment By: remarc (remarc) Date: 2005-11-08 18:55 Message: Logged In: YES user_id=1375403 Forgot to mention under 5: happens in case the values written are in a location above the current SP, e.g: xxx <--current SP low-address-byte high-address-byte <-- updated SP Problems arises if interrupt comes in before SP is updated and if ISR uses the stack. Regards, Jim ---------------------------------------------------------------------- Comment By: remarc (remarc) Date: 2005-11-08 18:32 Message: Logged In: YES user_id=1375403 1) Sorry Maarten, newbie here. I have now registered and logged in. 2) by accident. 3) I have done so and it solved my problem. 4) Not sure about that because longjmp() pulls tricks on the stack. 5) Let me explain: the code fragment from the original longjmp() that I have labelled "critical section" here first writes a return address (saved from a previous call to a corresponding setjmp()) to the stack and then updates the stack pointer: *((unsigned char data *) lsp) = *bp++; *((unsigned char data *) lsp - 1) = *bp; SP = lsp; If an interrupt comes in after the first or second statement AND before SP gets updated in the third statement AND if the ISR starts saving values on the stack THEN the two stack bytes just modified get clobbered by the ISR. As a result longjmp() doesn't return to the address set by setjmp but jumps into some random code location. Am I making sense? 6) Default options, small memory mode, non-reentrant code Regards, Jim ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2005-11-08 13:55 Message: Logged In: YES user_id=888171 Jim, 1) It helps (YOU) if you log in before posting a bug. You get email notifications of changes to this bug report, you can change settings, you can upload files, you won't get spammed because your email address is in the open, ... 2) No need to double post the PS 3) If you want to override a function in the library you can just write it and include it in your project. The linker will search your project before it starts looking in the library. 4) Instead of accessing EA you can also use the keyword critical 5) I do not understand how an interrupt can clobber up the stack frame in this case. 6) What options to SDCC did you use? Maarten ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-11-07 18:28 Message: Logged In: NO P.S. This applies to the MCS51 library -- Jim ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-11-07 18:06 Message: Logged In: NO P.S. This applies to the MCS51 library -- Jim ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1350513&group_id=599 |