Click Here
home features news forums classifieds faqs links search
5630 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)



Lost Password?

Don't have an account yet?
Register now!

Your support is needed and is appreciated as is primarily dependent upon the support of its users.

Main sections
OS4 Zone
IRC Network
AmigaWorld Radio
Top Members
Amiga Dealers
About Us
Terms of Service

IRC Channel

Who's Online
 72 guest(s) on-line.
 1 member(s) on-line.


You are an anonymous user.
Register Now!
 gregthecanuck:  3 mins ago
 Debaser:  6 mins ago
 klapdeur:  7 mins ago
 broadblues:  12 mins ago
 lionstorm:  19 mins ago
 Templario:  29 mins ago
 sTix:  33 mins ago
 sibbi:  54 mins ago
 Jasper:  1 hr 42 mins ago
 NutsAboutAmiga:  1 hr 52 mins ago


Main »» OS4 Screenshots

More official AmigaOS4 screenshots from Hyperion (17-Aug-2003)  Popular
(Read 68299 times)
These shots demonstrate the debugging capabilities under AmigaOS 4. Two programs are involved in this: The Grim Reaper and gdb. The Grim Reaper is the replacement of the old-style Guru requester (or the WarpOS crash window under WarpUp). It is automatically started whenever a program crashes. gdb is the GNU debugger, possibly the most powerful open-source debugger available.

Click on thumbnails for larger view.

Shot 1: 'lawbreakersg' is a small program that simply does an illegal access, similar to the old 'lawbreaker'. The result of this is the "Grim Reaper" window. This tab (the "general" page) shows all general crash-related info that could be collected, like the registers, crash location, exception type, and which module the crash location belongs to (if the crash happened in a shared library, this would be listed under "module" in the crash location section).
Shot 2: The button "Write Crash Log" dumps the relevant information to a file. This is the editor displaying this file. It can be mailed to the developer for improved bug reports. As you can see, it also includes a stack trace (see also shot 3) with function names and offset within the function, as well as listing the section within the ELF file and offset).
Shot 3: The Grim Reaper can also show the stack trace in the GUI. The top line displays the location of the crash itself, which happened in the function func3. Note that all of these addresses are internal for the lawbreakersg program; external references, for example from a library, would be prefixed with the executable/module name. This makes it easier to track the error. However, local references are abreviated like this to make the output more readable.
Shot 4: This is Thomas demonstrating gdb. Thomas had been hard at work to complete GDB support, and the result is that we can now debug OS 4 native programs on a source code level. This demonstration shows how gdb intercepts a crash in the 'lawbreakersg'.
Shot 5: Thomas' gdb port also has the ability to attach to a running task, at any time, even after a crash. When a program crashed, the Grim Reaper offers the possibility to attach gdb to the crashed program. The result is the same as if you would have loaded it under gdb's control. Gdb's attaching feature also works if the process is running normally, in which case the program is frozen and put under debugger control. You can now start to examine (and change) variables, single step, continue and even detach gdb again (and, of course, reattach later).

(Note: Shots four and five show the command-line interface of GDB. There might be a GUI for this later).

View comments / Post a comment - MikeB
[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 was originally founded by David Doyle