[M3devel] RTOS.Crash

[Tony Hosking]

OK, cool.

On 11 Dec 2009, at 10:07, Jay K wrote:

>  > We should do the same for POSIX too I think.
>  
> Posix just calls abort.
>  
> Posix:
> PROCEDURE Crash () =
>   BEGIN
>     Cstdlib.abort ();
>     LOOP END; (* wait *)
>   END Crash;
> 
>  
> Win32:
>  
> 
> PROCEDURE Crash () =
>   CONST Magic = 1 * ADRSIZE (INTEGER);  (* == offset of "fp" in this frame *)
>   VAR fp: ADDRESS := ADR (fp) + Magic;  (* == my frame pointer *)
>   BEGIN
>     IF WinBase.IsDebuggerPresent () # 0 THEN  (* I moved these three lines up. *) 
>       WinBase.DebugBreak ();
>     END;
>     RTThread.SuspendOthers ();
>     RTMachInfo.DumpStack (LOOPHOLE (Crash, ADDRESS), fp);
>     RTSignal.RestoreHandlers (); (* so we really do crash... *)
>     Exit (-1);
>   END Crash;
> 
>  
> That said..I'm missing something and I should review the code.
> Obviously there are calls elsewhere to DumpStack, and they or may not be similarly crufty.
>  
>  
> /Actually/ one thing I'd like is for the m3core to be able to dump better callstacks.
> Like, the ability to carry more debuginfo of its own custom format in itself.
> Like, to get line numbers.
>  
>  
>  - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Fri, 11 Dec 2009 10:00:35 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> We should do the same for POSIX too I think.
> 
> On 11 Dec 2009, at 12:42, Jay Krell wrote:
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 09/12/11 12:42:57
> 
> Modified files:
> cm3/m3-libs/m3core/src/runtime/WIN32/: Tag: 
>                                       release_branch_cm3_5_8 
>                                       RTOS.m3 
> 
> Log message:
> port from head: very small change that makes debugging sometimes much better
> (break right into debugger, don't waste time trying to suspend threads
> and dump stacks, the debugger does a much better job of suspending
> threads and usually (if you have symbols) of dumping stacks)
> If you aren't using a debugger, then no change.
> 
> The thing about RestoreHandlers can probably just be removed since
> in my brief experience the DebugBreak works fine before it.
> 
> Really it can probably just go like this:
> If debugger
> debugbreak
> ELSE
> suspend others, maybe
> dumpstack one of the important parts
> restore handlers probably can be removed
> Exit(-1) also important though maybe should be TerminateProcess which is much quicker/cleaner
> doesn't run all the dllmains
> 
> though currently I just made the small change of moving the debugbreak much earlier

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091211/918adf76/attachment-0002.html>