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

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
Home
Features
News
Forums
Classifieds
Links
Downloads
Extras
OS4 Zone
IRC Network
AmigaWorld Radio
Newsfeed
Top Members
Amiga Dealers
Information
About Us
FAQs
Advertise
Polls
Terms of Service
Search

IRC Channel
Server: irc.amigaworld.net
Channel: #Amigaworld
Channel Policy and Guidelines

(Uses JAVA Applet and Port 1024)
Visit the Chatroom Website

Who's Online
 57 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 wolfe:  14 mins ago
 outrun1978:  27 mins ago
 OneTimer1:  31 mins ago
 AP:  36 mins ago
 pavlor:  38 mins ago
 Severin:  53 mins ago
 Rob:  57 mins ago
 Gopal:  57 mins ago
 eliyahu:  59 mins ago
 portarinos:  1 hr 11 mins ago

Features

Main »» OS4 Screenshots

More official AmigaOS4 screenshots from Hyperion (17-Aug-2003)  Popular
(Read 67394 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 ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright 2000 - 2017 Amigaworld.net.

Amigaworld.net was originally founded by David Doyle