Debug 101 (v.0.9)

Version 0.9 of Debug 101 is now available:

http://dl.dropbox.com/u/5482530/Code%20examples/db101.lha

Added since version 0.8:

- Arexx port
- Arexx console
- Bugfixes and more

Added features since version 0.7:

- Attach mode
- Breakpoint window doesn't block
- Lots of internal changes

Added features since version 0.6:

- Interpretation of typedefs (experimental)
- Correct type-relative printing of variables
- Reading of global variables
- Read fp regs

Added features since version 0.5:

- Complete restructure of breakpoint system
- Correct handling of loops (experimental)
- Asm step and asm skip
- Tonnes of bugfixes
- Several other small things


Problems:

There are some problems with elf.library.kmod in AmigaOS Update 1 and Update 2, so from this version it is only going to work with a pre-update 1 elf.library or with the latest beta version (53.13). Sorry for this, but there is no workaround .

There is also a problem with the msr register, which means, that if you by any chance place a breakpoint on top of a branch, things are going to mess up. Sorry, this is also not my fault!

There is a problem with the gnu linker, which means that reading of type definitions doesn't work properly for executables consisting of more than one source file.

@alfkil

That cool ! Cant try it for now, but maybe you can briefly explain what it can do for now, and what it will to do ?:) It will be the debugger with all those breakpoints and alt, or it also will have some disassemble function , or maybe little hex viewer ?:) (like in GDB). Will it be "console" debugger like gdb, or it will have any kind of gui ?

Anyway, that pretty interesting that someone start to work on such project. Nice !

@kas1e

I can explain a little: It is just a very small app, that can load a module, set a breakpoint and run/pause the app. Ideally it should also be able to crash the app, so you can read the stacktrace etc in the grim reaper, but that part doesn't work for some reason.

I want to be able to single step through the code when it has paused, but for that I need to be able to read and understand debug info, and that's where I'm stuck for now.


EDIT: and yes, it has a gui!

@alfkil

Quote:

Nice. I will give this a try.

Coder

@alfkil

Are you passing the tags a BPTR to the directory lock?

@tonyw

Doh! I need to start reading the docs properly... Thanks!

@alfkil

Good for you alfkil!

perhaps in a year or so when I've achieved a reasonable level of compentency in coding C your applicaton will be the next best thing since sliced bread?

@alfkil

It's very much welcomed !!! Great !

I discovered a little problem though select the provided HelloWorld sample, run it, then when the display says execution ended, if I click on "Set breakpoint" Debug 101 is reaping and can't be used any further.

I briefly tried to debug "DEbug 101" while debuging "Hello World" but wasn't able to spot where the problem occurs (it was late and was needing a good sleep).

Anyway I wish you good luck it's promising !

@alfkil
Tested. Can say that is pretty good for begining. Simply and nice interface. Still not very usably maybe, but very promising (if you will have enough motivation and time to mature it).

I tryed also to load "heavy" programms, not just hellow word or db101 bins, and i tryed : AmiFig, Lodepaint (heavy one really), one opengl demo (Arte Dominium) and Quake3. All apps runs over debugger nicely. That is really big + for you for the first version. For me it personally show that your project are really promising.

Few thinks for your (maybe) todo list:

engine ones:

-- give user a solution to set breakpoint not only on symbols, but also on any address of user-space where is programm will be runs (and not only on address of user-space, but on any address at all. Because we not have so much memory protection and alt, debugger can read any area).

-- give user a possibility to disassemble any area of the programm (of any range), even, if no crash are occurs (that very handy stuff in GDB, which give you freedome to watch the memory while programm working, wath some register states, and just disassemble any C functions to asm, when you work on some high-level stuff).

In general i think we need to found all the "plus" sides of GDB, and put it to your debugger (if you will want to do it of course:) )

interface ones:

-- remember (while debugger are running, or also when it will quit/start) a last directory which was visited. I.e. when user press "select file", then it spawn a last visited directory for.

But i relly enjoy that someone start such project. That is VERY COOL ! When project will mature enough, Rigo can add it to his CodeBench. I always was in high interest about debuggin not only on aos4, but in general. And having ability to browse the programm not from code, but "in deep" it always interesting. That can help to found many bugs, even if GR will not catch them.

For example, those MemGuard bugs, with additions with breakpoints on any addresses, can help to monitor where exactly in programm bug start to happenes, and by dissasble understand why.

Also maybe you need to add that project to openamiga /amigabounty. For sure such effort should be payed, or maybe more coders will in interest to works with you on it.

PS. For everyone in interest, there is screenshot of debuger in action, with q3 over it (press for full-size):

@kas1e

Nice screenshot

1) I have added path-memory to the asl-requester.

2) I totally agree with you, that it would be nice with more developers to contribute to the problem, after all, I'm just a lazy no-good amateur with a lot of spare time . Also, adding it to Codebench (once it is done) was one of my initial thoughts.

3) I might try and add a simple disassembler and breakpoints at absolute memory locations. For the rest of the parts, I'm pretty stuck at the moment not knowing how to read and interpret debug info from object files. I was hoping, that someone in here had some knowledge to share, but maybe that's not the case...

@alfkil

Regarding the integration within CodeBench, there would be no need for a GUI, and the debugger would need to work via IPC or some sort of machine interface.

The editor gadget used in CodeBench already has all the features required for source level debugging, like breakpoint highlighting etc.

TBH, once you get the dwarf2 or stabs debugging information to be accessible, I'd be interested in taking a look at what you have with a view to building a debugging plugin from it.

Keep up the good work.

Simon

@abalaban

Thanks for the pointer, it has been solved (me thinks).

@alfkil

This is maybe THE most waited tool for AOS4 programmers and betatesters

Thanks a lot for starting this project because It's often too hard to have great output to send to programmer when a problem arrive on a tool (C or assembly).

I really hope that you will have some greatly help from another AOS4 programmers for improving your tool.

I'm myself verry interested to test and use this kind of tool for debugging


Also I have seen you have lots of free time ?? Incredible.

During your free time, could you (It's a thing I ask often because this tool miss me a lot update snoopdos ???

Snoopdos AOS4 not work anymore because something has changed that can't allow snoopdos to show output. Maybe just a compiling time is only needed....

@Mrodfr

Snoopdos replacent is Snoopy, not every functions from SnoopDOS are present yet but maybe asking kindly Colin the one you miss and he might add them...

@Mrodfr
Quote:
SnoopDOS is long obsolete and broken on 4.x. Use Snoopy from now on which is fully maintained and works correctly. Snoopy was created by the guy doing dos.library so you know it works.

@ssolie

why snoopdos can't be updated ???? sources are available...

@Mrodfr

Maybe because internals changed so much that it would cost more to try to update snoopdos so that it still works under AOS4 than to develop a new program from scratch.

Especially if one wants to share source code with other Amiga like systems it would either be an horror to maintain (full of #ifdef) or only the least common API each platform still share with each others (so least powerfull)...

@Mrodfr
A good debugger seem to be something all developers would benefit from.
Regarding Alfkil's freetime I'm not so sure that is a positive thing, at least not for anything else than his software development

@Alfkil
Keep up the good work!

New version of DEbug 101 uploaded. See original post for details.

@alfkil

Quote:

What does that mean ????

The problems are reported on the AOS4 bugzilla ???

Your program not work for example:

unrar source destination.

source and destination can't be added on your program. work only with unrar command.