SpotLess debugger

So, just to clarify, does the latest version need beta kernel? I downloaded a recent one a few weeks ago and it ran fine. Well it did actually work for me.

Things can progress fast in the OS4 world. Maybe adding a beta and keeping the current working one would be good. So anyone who downloads the latest stable doesn't need to be a beta developer.

@Hypex
It requered beta kernel on x5000, on other machines (such as x1000) it may works, just with some bugs (line hanging on exit or crash on tracing).

But ! As we all know your setup is mess of old and new components, not pure latest ones , then you can have all sort of other issues which no one have.

@nbache

Quote:

I agree with Niels. This is not an error, although the basis of making the programmatic decision is made from an error return variable from IPrefsObjects->ReadPrefs(). From the users perspective this is not an error and should probably just be given as neutral information in the Console window.

@elfpipe
@elfpipe
First of all, thanks for working on Spotless.

I tried running it on an X1000 using the released kernel, so anything I say here can be ignored if that's the problem. Here are a couple inputs I have from running spotless on the included "test" program.

1. In the source code window I set a couple of break points and stepped through the program. I would expect the highlighted line to move to the currently, to be excuted line, as you step though. It
doesn't move at all on my system.

2. While stepping though, when I get to the end of the program the program seems to be unloaded from Spotless and I have to load it back in to do more debugging. Shoudn't the program remain loaded when you get to the end so you can continue debugging?

@ktadd
I checked the "2" , and for me programm unloaded only when it reach end : i.e. i have put breakpoint on latest "}" , and hit start : it breaks there. And of course, hit the next "start" will then going futher and finish the execution and unload from.

I will check on x1000 tomorrow, maybe it act different , but the correct behaviour is that once you reach etc (by end, mean that you can't set any break point anywhere after), then it unloads because it ends. But latest "}" should works for breakpointing (at least on x5000 and latest kernel it is).

As for "1", yes, that there is bug indeed : it just stays on a place where you hit breakpoint: in other words, highlighing does not follow to the actuall breakpoint position, that sure bug.

@kas1e
Quote:
Yes, that is the behaviour I'm seeing. What I would like it to do is not unload at the end and allow me to do a restart on the debugging. Kind of like an automatic break point at the end of the program and then be able to set new break points and "restart" the program from the beggining so continue debugging. Maybe a clear break points feature would be good as well. I think this is not as much of a bug as it is an enhancement request.

@ktadd

1) This is a bug, that sneaked in during the last phase of development. I will do a fix - it is fairly easy - and do a patch release within a few days. Thanks for reporting!

2) This is the standard behavior for executables in AmigaOS. I am just using standard functions to load and run the application. In normal DOS mode, you also have to reload an app, when it has finished. There is no such thing as "keeping in memory", or "restart".

@alfkil, ktadd
Imho reloading can be done or via another button in gui, or via RMB menu like "reload the last binary". It will be of course just mimic the same load button just with remembered last path of the loaded binary and automaticaly take it and load, without asl request.

Another question of course if this feature worth of it.. Can be handy, especialy if there will be a shortcut for. Of course be it rmb menu or gui button this will be ghosted out until at least one binary loaded and finished properly.

@elfpipe

Sent you a PM

@kas1e,alfkil
Quote:
Yes, a reload button would be great!

@ktadd
Yesterday there was a new version released that, among other little fixes, dealt with highlighting when we traced things. On my setup, everything works fine now.

@kas1e

Okay, lots of focus on X5000 these days. The last version was the only one I've tested that worked on my X1000. Previous ones were too unstable.

But, as you would know by now, I can't run the latest pure components because they freeze on my system.

@Hypex
Quote:

It's just that we test it mostly on X5000, and the issue with the kernel was only X5000-related, so that's the reason you need a non-public kernel to make it work on X5000. But that's only about X5000; other systems may behave correctly with the debugger with the latest public components; it's just that we didn't check on other hardware much (but I will do so in the future if Alfkil does not die of my bug reports).

But anyway, even on other systems, it means you should have the latest public components (including kernel, elf.library, and whatever was released in Update 2). With the old system you have now, your reports can be flawed and can't be considered because of that. But that's just my opinion as a beta tester; maybe Alfkil is interested in tinkering with the setups of non-up2date users :) )

@Alfkil
Cool article! You surely need to made a pdf of it and distribute inside spotless archive.

Do you have any plans to improve it more ?:) im here for some betatesting as always :)

@kas1e

I have no plans for updates at present. Not too sure, what would be a good plan for further development. Do you have anything specific in mind?

I have one.. debug .libraries..

@elfpipe

Maybe if "Memory surfer" listbrowser use fixed width fonts.

In in main windfow in Dissasembler and Registers tabs to a fixed width font.

And in Console tab the colors/pen (yellow, don't know other you use) can't be read on "typical" grey background X-)


And I get a Spotless console/window with a lots of:
...
address : 0x5f9acdc4
address : 0x5f9acdc8
address : 0x5f9acdd0
address : 0x5f9acdd4
address : 0x5f9acdd8
address : 0x5f9ace3c
address : 0x5e35f0a0
address : 0x5e35f0a4
address : 0x5e35f0a8
address : 0x5e35f0b0
address : 0x5e35f0b4
...

@afxgroup

This is difficult.

@jabirulo

Those are valid points and not too difficult to fix.

So, this relies on libraries that are all now publicly available? I remember that there needed to be an update to elf.library and the kernel.