Screenshots demonstrating AmigaOS4 debugging capabilities

[redfox]

:lol:  .... good one amigamad

One of my buddies at work sees "the blue screen of death" on a regular occurance.

---------------
redfox

[Rodney]

Im a little bit worried about the debugging... Great feature, but the thing with gdb is a little weird. I know that, when you compile unix apps under gcc, you have to compile with a special flag if you want to be able to debug with gdb... The extra flag does something to the code, puts in sometype of debug table? i dont know... it does something, and this adds to the overall executible, does it not?

Its also known that adding debuging features into a program can slow it down and make more resource hungry...

Is this the case for AmigaOS4 binaries? I would think that most users (and i admit AmigaOS users arnt most users wouldnt want the gdb features, if it was going to comprimise performance in any way... I would think the gdb features would only be for beta testers/debuggers/developers of AmigaOS4 or their specific applications??


I just want to know, will adding gdb support to applications add any extra code or sometype of information to the executible so that gdb can track each execution of a statement in a program?

If something is added, is this considerable enough to slowdown the applications, either at load or run time?

Does it make it more memory hungry? <-- i guess that would be true even if only several killobyte of something was added to the application to provide this functionality...

Im pretty sure all of the above happens, and i wouldnt mind whilst i was debugging an application that i made. I just would want the above to be true for end user AmigaOS binaries, such as the TCP/IP stack or the kernel :} - although, i think i've just understood that maybe the article was just demonstrating what can be done whilst developer your own applications?

[Rodney]

No screenshot of a Guru Meditation!

The Grim Reaper is the replacement of the old-style Guru requester (or the WarpOS crash window under WarpUp).

same thing?

[CodeSmith]

@Rodney:

Developers usually create two versions of any program: the "debug" version and the "release" version.  Both normally share the same source files.  The debug version normally has all sorts extra optional bits (in C, this is done with the "assert" macro) that programmers use to verify the flow of data in a program, that do not get compiled into the release version.  Also, compiler optimizations are normally disabled in the debug version, since this causes the compile cycle to go a bit faster.  Once the programmer is happy, he will produce a release version of the executable, and that's what ends up on aminet :-)  So any debugging information will typically be only in the debug version.  To put it technically: you will normally invoke the compiler with the "-g3 -D_DEBUG" switches for the debug version and "-O3" for the release version.

However, gdb is a very smart program, and can show you some useful information even on a release version of the program.  You just get a lot more info on a debug version.

[Rogue]

same thing?

It depends on what you call "Guru". In OS 4, there's three things:

- The red/orange blinking box (aka Guru Meditation)
- A plain requester stating that program X has crashed
- The Grim Reaper window.

The blinking box is still caused by Alert(), and is usually only used for desasters like a corrupted memory list and such.

The plain requester comes up when a program has crashed. It has a row of buttons like "Kill", "Reboot", and "More...". The latter will bring up the Grim Reaper window.

[ikir]

Very good job Hyperion!

[benJamin]

Once again, I was compelled to move my mouse to a scroll bar or two to see more contents of notepad and listers.

I'd like to tower my A1200 with an Amiga One and use two monitors...

Just a thought. :-D

My putting away money for AOne OS4 at the moment is still worthwhile. :-P


benJamin

@Hyperion
I've been waiting this long, I'm not going to let all those people down.

Your hard work is justified.

[olegil]

Actually, you'll get debug info for gdb in the elf no matter what you do with the compiler. Later on you can run it through strip to save space (strips off any debugging information).

But you don't have to run gdb unless you want to, you know. And people don't have to distribute non-stripped binaries unless THEY want to. The choice is a good idea, though :-)

[Rodney]

I initialy posted that assuming that all amigaos4 binaries were going to be debuggable useing gdb for the end user... Such as, if Roadshow crashed you could attach jdb to it, or if another OS4 feature crashed you could debug it with gdb...

However, now i assume that will not be possible since i assume that the end user binaries in the OS4 distribution wont be compiled with any debuging flags... correct? I was hoping not because of the reasons you and i outlined... :}

[Glames]

Hi,

simply excellent!

Thanks

Tcho,

Glames

[Rogue]

However, now i assume that will not be possible since i assume that the end user binaries in the OS4 distribution wont be compiled with any debuging flags... correct?

Correct. Usually it's "no user servicable parts inside". There is no reason to ship binaries that have two or three times the disk consumption for the rare case that something crashes, and the user in front of the machine is sufficiently familar with a debugger to actually handle the situation.

Besides, you don't want a would-be hacker to sniff around in your shareware or commercial program for that CheckCopyProtect() or ReadKeyfile() routine :-)

No, debugging features are for developers. But I am quite sure that most developers will appreciate the feature, and most users will find that it is easier to get bug reports with meaningful content to the developer, which in turn means improved quality for software ;-)

It's a win-win situation.