Debug 101 (v.0.9)

@Mrodfr

I think alfkil means that due to problems in elf.library present in AOS 4.1u1 and AOS 4.1u2 his program only works on plain non updated AOS 4.1 or on latest AOS 4.x beta.

For the rest I don't understand your example about unrar.

@abalaban

I think he mean that arguments can't be handled by programm.

@kas1e

Yes, arguments can't be handled by the debug program.

handled word is better than the added I have choosen, sorry.

@Mrodfr

Okay so basically you are asking if the whole program or only some of its functions are incompatible with current public AOS 4.1 versions, aren't you ?

@alfkil??
Tested new version: run the db101 binary (wihtout setting of BP), then exit from db101. Select HelloWord, run, and crashes in the elf.library.kmod. But i think it is ok if you say that its buggy in public versions for now ..

@abalaban

Quote:

no. I have tried to see this tool debugging unrar. launch the tool and choose unrar and immediately the tool run.

impossible to choose a source data and a destination path, to see if Debug101 debug unrar during his decompress phase.

debug 101 degug a tool program and not a command line.

@Mrodfr

Okay so in fact you are asking alfkil to add the possibility to pass a commandline to the debugged program prior to its execution.

This is indeed a good feature request.

@abalaban

Talking about feature requests, the amigabounty team
seems to be thinking about opening a bounty on a
source debugger with gui such as db101. I this becomes
a reality, I would like to ask people in here, what they
want/need from such a program so that the bounty can
be guided towards the people and not vice versa.

So... What do you all want??

EDIT: Passing of arguments will be added as soon as I get back home.

@alfkil

If you want to make a real debugger (like GDB or kind), then imho it should be logical as possible and easy (but easy not mean less features of course). The list of "wishes" can be very big (i can write such, if you in real interest), but in general, just making it GDB like, or Monam (old 68k debugger) like , or any other debugger like. Mostly they all have the same features, just differently designed.

Imho will be cool to have something like one "working window", where you can type commands (not only pressing buttons by mouse), type addresses and so on, and other windowses some of which can be only for info, some of them can change values too.

-- list of C functions from libc
-- list of user functions if -g was provides.
-- disassembler window
-- hex-viewer window
-- registers info window (with all those stack pointers, r0-r32 registers,etc)
-- information window (address from which in memory process will be started, how big is it , and other stuff which can help to do debugging).
-- memory stack window (to show current memory state while programm working)

It also should be (imho) interactive. I.e. you can do "step" by assembler instructions (not over full functions).

For example when you run programm, and it works, you can for example press "pause", then go for example to disassemble window, where you can interactive do "step" command.

Well .. its all the same features as on any other debuggers on any OS.

For example, for Win32 i like a lot OllyDebugger (one of the best ones for win32):

Screenshot1

Screenshot2

Or few simply ones:

CPC debugger (WIN32, but for Z80 cpu)

syser debugger (DOS)

They all do the same, and their look almost the same on every OS, be it or AOS3 (dtp , monam , sasc debuger), or win32, or linux with gdb/any_front_end (i mean look of UI, which give developer all possible information in easy way).

Of course for example GDB are fully interactive, but only one window are here, which are pretty much changed by full interactive mode, by which you can do all what you need. Also there is many front-ends to make GDB the same as all other GUI debuggers ..

@alfkil

Quote:

Desired features (including ones that you already have):
- An API so that Codebench and other IDEs/code-editors can use the debugger (having a standalone GUI isn't important to me)
- Set breakpoints, and watches
- Step though programs
- Get a stack trace at any point, as well as the CPU state
- Examine the value of variables, including structures and C++ class fields (think of the way that Visual Studio does it)
- Debug an application whose debug info is in a separate file (e.g., I have MiniGL.library, but the debug symbols are held in MiniGL.library.debug)
- The ability to modify variables and even move the instruction pointer (e.g., to skip the next instruction)

Hans

@alkfil

There are also the valgrind working start from sba (surely too big but in case you haven't seen that before):

http://www.amigans.net/modules/newbb/ ... e=&topic_id=4091&forum=25

I would like to see debug101 also as a standalone program. the simple user should use this program easily for reporting problems to the developper.

@Mrodfr

The good debugger never will be easy for users (you need to know how code, you need to know what is breakpoints, assembler in general and assembler instuctions, you need to know what is stack pointers, what is stack, memory layoyts and so on). Any debugger its mostly for developers, not for end users. And in general it will not help simply user in any way (only a few maybe, in a very few situations). But will be help a lot to developers, while they works. And of course, it will help to found bugs, but again by developers only. Knowing how to use debugger, its big area of other side of programming, and its requeres some programming skills in any way.

Valgrind are good too, yes, but its not debugger. Its more likely "bug hunting tool", which are good to have too of course, but that is not gebugger (too different purposes). The good example of wellknown debuggers its GDB on linux and Olly on Win32.

@kas1e

Quote:

The valgrind-framework is originally intended to be an instrumentation framework (actually, my probably never finished work doesn't provide a port of valgrind but something on top of libvex). You easily can (in theory) inject breakpoints as well and make it more interactive. It is probably not needed in the Linux world as they are decent debuggers available. The difference between the "valgrind"-approach and a normal debugger is that the "valgrind"-approach emulates the CPU while the latter runs the code directly (and thus is faster, and probably faster to code). I also think that newer version of GDB come with a CPU simulation.

@sba

Btw, maybe a bounty will a bit motivate you to work more on it ? Imho 1-2 thousands can be collected for such important project with no problems.

@kas1e

I like Muforce on AOS3.x because I run it on a script and I send the catched hit and the programmer resolve the problem (generally and verry often).

With AOS4, It's not the case and the programmer have dificulties to found the problem. Grim reaper not work well allways and sometime AOS4 freezed without grim reaper (boring) and sometime the programmer is lost with the Grim reaper, GDB not uptodated, memguard exist but, for example, when the memguard hit for USB copy, nobody know what happened with this memguard,etc.....

I'm searching desesperately after a debug tool, launched on the background who catch ALL problems and are able to save the output for the developper. An output with ALL necessary inside to found the problem.

As you have seen, no technically langage programamtion sentences since the beginning of this answer but I really would like to save the freetime of the programmers with a gret output when a problem arrive with an AOS4 software.

If debug101 and/or valgrind could be a candidate for this task, I could fill a lot a bounty I can't help by programming but I could help with some money..


But the problem isn't the bounty because It's more easy to found money than an AOS4 programmers with skil and free time.....

@Mrodfr

A debugger won't do what you are saying. A debugger only helps a developper to find bugs by allowing him to run the program step by step, see which execution path it takes and examine change in any variable. It's purpose is not to produce readable output when a program crashes.

For that Grim Reaper is here. Yes sometimes the system is completely halted so log can't be stored and that's a problem (which can generally be worked around by hooking up another computer via serial link and capturing the output). If a programmer is lost with a Grim Reaper log then either:
- it's because he does not really develop/use AOS4, only cross-compile his program for it, and so isn't familiar with its output;
- it's because he didn't do the right thing to produce a debug information enabled version of his program, so unless he's very good at dessassembly and register dump reading yes he won't be able to spot the location of the bug, (with a correctly produced debug version a Grim Reaper log will allow the programmer to retrieve the filename, the function name and the line code the crash occured);
- both of the previous.

Quote:

Well, see that's the problem: Money is not a big deal for someone like me, rather it is the question if I'm able to actually do it at all. If I'm able to, I'll do it no matter if there is a bounty or not, but if it turns out I can't do it, well, money is not going to help a lot here...

@alfkil

We always can add to bounty that phrase: "author should provide his latest sources", and when you will feel that you tired and not in interest to work on it, or just want to join force with someone else, then code will help a lot. Later anyone can grab your sources, and works with it. That of course a bit suck will be, but still, better than nothing.

@kas1e

That's a great idea.

@kas1e
If possible, I would recommended that the development of the debugger takes place in the adtools repository, which is the standard repository for development related software for AmigaOS. With a collaborative approach, each interested dev can at least work part time on the project.