Spotless vs. c++ stdlib

Just to let everyone know: There are issues in the latest c++ stdlib in handling conversions between string objects and 64 bit numeral types. This is a huge problem for Spotless in limiting cases (it will crash). There is no solution at present.

@Alfkil
Do you mean in one comes with aos4, or in your one comes with spotless ?

@kas1e

Spotless will not work with the version of c++ stdlib that comes with the os. It needs the "special" version (= latest adtools).

Even in this case, it will give inconsequential output, or crash, when there is a conversion between strings and 64 bit numerals.

This includes the case, where it tries to debug itself.

@alfkilI

just peeked in the installer script and...
...you probably shouldn't overwrite the users libstd++.so in sobjs:

rather use your own sobjs/ in the programs dir, otherwise some other programs may stop working for the user.

@kas1e

Try it with the shared object crashes, maybe this will shine some light on the matter?

@alfkil

Yeah, it's crashing right when i load in a binary (GUI version)

Yes, replacing original libstdc++ are bad idea, i told the same before :) For example, it will broke SDL1 apps which uses shared versions of SDL1 , which use shared version of libstdc++.

@Alfkil

In other words, there should't be installer. Just creating of SOBJS in the root of spotless archive and put your sobj there, and remove installer script. Then all will works, and nothing will be overwriten. Because as it now, some ppls may install it, forget about, but will have other version of libstdc++ which will (and it will) cause issues there and there just because its different.

@Raziel

Yes. Which is why you need to load an executable, that makes sense. I have not clearly stated that in the readme. Apologies. You need to build your executable with -gstabs for both the compiler and the linker. Then it will work.

When testing software, the best strategy is not always to make it fail. It is also relevant to confirm actual core functionality. Who knows, maybe it hides something of value to the community.

Status of Spotless 1.0.2 today is, that it can load and debug itself. Most c++ specific data is unavailable, but core functionality is there, crashes have been exterminated, and everything will be possible to add in time.

---

I am not the one to ask for applause. But really I think it has come along way since work started beginning with the Corona outbreak. My hope is, that it will be useful. That's all.

---

@Raziel and kas1e

I have noted the point about the local sobjs folder. Totally forgot about this feature and was grasping for a quick solution. I hadn't actually imagined, that it would break compatibility with other applications. Apologies. It will be fixed for the coming release.

@alfkil

But i did load in an executable, compiled and linked with -gstabs

Maybe the executable is too big? (~69 MB)

@Raziel

Cool. I fixed a few things today. Depending on the strangeness of the executable you are trying to debug, I am guessing you should see some improvement when using version 1.0.2. Unless, of course, if you are already bored and redirecting the issue to the trashcan.

@alfkil

Pff...yeah right, as if i'll let you off the hook now

Going to wait for the new release and test again (once i'm back home again, that is)

@alfkil

Quote:
Considering that Spotless is not a port, why not use a proper Amiga version string?

Can we PayPal you a donation?

@trixie

I'm currently at school and sticking to conventions of order implemented here. I have been out of the Amiga game for so long, that I get dizzy just from booting. :)

If that's a request, I will reopen my PayPal account. Thanks :).

Spotless is now able to debug itself.

Click --> Spotless

@Alfkil

OK, donation sent. Keep it up, jazz maestro

@Alfkil
Tested latest version. New buttons are good :)

But there is list of what i found (sorry for long report, i know you love it :) :

1.

Loading of itself indeed works now (through by some reasons not very fast, and some "loading" progress bar appears), But then, once you hit "start" : it start second instance, all fine. But quit from that second instance cause crash in AmigaProcess_readContext(). Ignore DSI helps.

The same crash can be reproduced by simle :

Load test binary, set break point on line 20 (printf hello world) , then "step out" , and while we have printed "hello world" , we also got a crash. Same crash in AmigaProcess_readContext. Ignore DSI helps as well.



2.

When we choice to load "test", then , while in the source files "test.cpp" entry are active, the window where should be source code are empty. So we need again click on test.cpp. Imho first source file in list should be shown automatically.


3.

Is that script for "assign" need it ? I was under impression that we can no more rely on it, and just use "PROGDIR:" in the code of apps.

4.

In the "variables", when we hit "Globals" button, we have always the same one added at bottom, and the more we press, the more added. Should't it refresh "variables" in whole , instead of adding the same ones at bottom of previous ones ?

5.

I was under impression, that "step into" should go inside of the system calls, right ? For example i set breakpoint on prinfs, then press "start" and once it hits on breakpoint, i then press "Step over". After that, pressting "step into" does not matter how many times i press it, its again on the same loop ( i can see from disassembly it jumps in the same place) and never doing anything else.

Then, after i press many times "step into" and it do nothing, then also pressint "step over" do the same as "step into". And also "step over start to be the same".

So seems (but can be wrong), that step into just die on going into syscall , and after that all other "steps" stop working. Only solution to close debugger.

It seems, that it happens when i hit a crash. Once i ignore it , it quit/run/ spotless again, it seems to work. Hope it not random. At least fixing crashes, should help to debug it futher.


6.

Minor suggestion : is it possible to add another gadget at right/top, where we can choice "snapshoot" , so we can resize the window as we want, choice that "snappshot" thing, and window will be of the same size on start as we want.

7.

Also iconify gadget will surely good as well, as when one debug things, it offten need to be in-the-work, just hided, and iconify helps.

8.

Just tried to load "Odyssey" binary in : it didn't start when i press "Start", because, seems debugger didn't take loaded programm's PROGDIR: into account, so if for example you tried to debug some app which will load something from its own PROGDIR: => fail.


Anyway, all that mean that if you want to improve it and fix things to make it all usable, then i am in to help with real deep testing, but there need to spend still some time for sure. I was even in surprise that you were in hope at begining that everything will works right aways without needs for bug fixes :)

But if it just proof-of-concept for someone who may find that code be usable later, then its good for what is it then, and no time spending need it :)

@kas1e

Hi Kasie, thanks for testing :). It is always good stuff to get your thorough investigations delivered. At this point, I have been forced to unplug my Amiga and put it in a closet, because I have a due assignment at school next week. Sorry, I didn't actually do it myself, but it had to be done. When I get it back, I will fix all the problems for sure ;).

Just to comment:

1. I cannot reproduce the issue here, but I have made a change, that might fix it.

2. I don't think so. When you load the binary, you will have the program counter in the startup code, so it would be wrong to show the user some place in the code.

3. It is needed for the CLI version shell to appear. But not for running any of the executables.

4. That is a mistake, and I have noticed it. Will be fixed. ;)

5. Step Into only works, when the step includes a subroutine call inside the sources. If there is a branch to a system function, it should just work as Step Over.

6. Ooh, that's an upper level user space request. Let's see, if I have time for those ;).

7. Simile.

8. I need to take care of paths. Those were not in my initial requirements. It has been noted. Thanks :).

To sum up your last comment : In fact this is all a play on the concept of bug free code. Obviously there will be adjustments as soon as the product hits the real world. But actually I am kind of baffled at how well it seems to be doing compared to the amount of testing invested in it previous to release.