GDB

@sTix

Absolutely second...if i had my XE still, i'd donate in an instant...

edit:
i'd also donate for the cause...

@sTix

Quote:
I wonder if Trevor's loan hardware program is still on? At any rate, the OS4 platform needs to have a way to provide a replacement system for key developers should they experience a hardware failure. We're already losing user base because of the perceived lack of progress and the quagmire we got into with the lawsuits. Losing developers would be a sure nail in the coffin.

@alfkil

Quote:


Thanks Alfkil, this is really useful. Yup, I've got a very basic helloworld program that I'm using as my test case .


As regards SimpleDebug, yup I'm using it big time and working on getting it into C so that I understand what magic your code is doing :) and then try and see what to do with that then. It's really useful for working out these GDB issues as it gives me a working example of debugging code that works correctly by stopping at a breakpoint.


As for the latest with GDB, I've got my test case where I'm setting a breakpoint at a given line in both SimpleDebug and GDB. I've added code to print out the memory 32 bytes either side of where they are both inserting the breakpoint instruction so I can compare where they are putting it. I can see that GDB is putting at a different place which would explain it not working, so I'm thinking that I've got the relocation set up wrong. I'd copied the code from SimpleDebug where it relocates the .stabs and .stabstr sections into GDB but it looks like I need to do more. Hopefully I'm now on the right path with this

And yes, getting you a working OS4 machine would be awesome!

@trixie
@Raziel

I wouldn't mind donating HW, but I really think it should be handled by a company or some other entity not made out of flesh and blood. Private donations can be a bit, I don't know how to put it, sensitive I guess. I think it's important that it's a no strings attached thing, no implicit expectations, otherwise I think people will be reluctant to accept it.

@sTix

I hear you.
We've all been there unfortunately.

I remember at least two instances that were funded privately and ended in nothing more than either a few pictures or nothing at all...needless to say, those individuals were soon to never be seen again...

@sTix, Raziel

Exactly. That's why I mentioned Trevor's loaner program. I once made use of it myself. It got me covered for a year when I couldn't use my own Sam.

@trixie

The problem with a time limited loan i see here is, that the loaner could feel rushed to finish whatever it is in the time frame and probably give up early due to time constraints or other commitments.

But of course, it would be a start

@trixie, Raziel & sTix

No worries. I have located a machine, that is both working, for sale and inside my price range. I hope to have it handy and set up before too long, and I expect there will be some cheering on behalf of the giver as well ( ;) ). Thanks though for taking considerations and valuable inputs up in the thread - it is of course ot, but I guess not so much, if I end up contributing the pieces of the puzzle, that makes the beast (gdb) run.

@billyfish

See... That's the complication, when one is not building own code but working on some codebase. You have no clue, what's going on. My suggestion is to spend time with the construction specifics of (in this case) gdb and get to know it well - well enough, so you can draw diagrams, hierachies and division in modules (or layers). These drawings can be very detailed and are best done - on paper - when you have a clear inner picture, after having studied the code by reading and notetaking for an extended period. When you have a feeling, that you know the tip-toes and tiniest details of what is in fact the construction of the software - then you should proceed to your own modification. If you do so before, you are not working in the correct way and end up flooding your brain with not so useful material.

...but on the other hand it's good fun to do so, so if you enjoy it, just knock yourself out ;).

@alfkil

Awesome, happy to have you back soon(ish)

@billyfish

Lately, ExecSG guys release some beta version of the kernel with a fix for x5000, so debugging interrupts working again, and I can run old GDB on x5000, and breakpoint works.

Wasn't you lucky to deal with our breakpoint crap in the newer GDB we tried to make?:)


@alfkil

Btw, with new beta of kernel issues with SpotLess are fixed too, it kind of works now (again).

@kas1e

Great news!

@kas1e

Quote:

What are the "kind of" not working spots?

@All

As billfish obviously seems to not have time for GDB, and that all anyway was slow enough and not enough for making a normal GDB port, i want to go another route:

I tried to hire on Russian freelance sites developer(s) on a payment basis (~7-8$ per hour, or about 1000$ per month) to make a port of GDB to AmigaOS4 (so I supply them with cross-compilers/emulators ready to use). I.e. those developers know nothing about amigaos4 and stuff but just will work as workers, learning in-process and co.

I, of course, know nothing if there will be a good outcome from this or not, but all I know (and hope), is it still will be better than our current situation with GDB, or our current situation with debuggers.

Sure, some of us may think why not hire Amigan for that: but we all know that most of us do it all for fun and hobby, other ones who can and want already hired by Trevor and Mattew, and those who want, have no skills/time/energy/clear-enough-mind. So, i go my own usual route to doing things with people far from Amiga world, and that usually finished up much better, especially when the money is involved.

Now, i already found a few, and we are in process of starting, but that just was a brief intro to what i want to achieve, but you know .. Anyway, there i want to discuss what we all now need for a normal GDB port to be usable.

What i think for now is:

1. Usual GDB (classic stuff, breakpoints, backtraces, stepy/next/etc).
2. gdb-server for remote debugging (give us the ability to use it from any other devices and debug things better)
3. support for "-tui" (inbuild graphics interface). At first, we may try Ncurses way (and fix ncurses where it needs it), and for a second if all going well, maybe native AmigaOS gui.

Those 3 i see as a must, but what else needs to be in our GDB port that other oses have?

Plz share your ideas about as well.

PS. GDB because i want myself GDB, and not another half-finished native debuger. I need something which proven to be ok by years and by lots of tests and different people contributing. And which will be polished till the death to be 100% normal usable debugger for all of us.

@kas1e

Sounds good! Regarding #3: I always liked cgdb which is also curses based. I don't consider #3 to be a must though.

@sTix
Btw, i tried some days ago to port some ncurses based things (by porting my own version of pdcurses) , but they are all buggy and seem endian-problematic. So that one need to be fixed in the process too.

Anyway, later i of course prefer if it will be something not like -tui, but also -aos4gui, so some reaction-based one. But that of course not must have right now.

What we need right now is pure working gdb and gdbserver with serial and tcp/ip support.

@All
Just some info about my crusade with GDB:

I found one interested English-speaking person who even did some small commits to the main GDB repo, who was willing to do the things. So far installed a cross-compiler + emulator and start experiments.

Also found 3 interesting Russian-speaking persons, they are also in process of cross-compilers/emulators.

So, the ones which will work faster and produce good output will be the ones with who i will try to work on. But other ones can be hired for other stuff to code, if, of course, they will succeed with basics and will have interest in. By other stuff, i mean all other sorts of things like updating Binutils or writing some new driver for something, or all that "hardcore" sort of things.

I.e. all sounds optimistic, but at moment it's all only at the start. But with GDB I am 100% will be dealt till death until we will not have a new working version of GDB. Even if not for them, i will find someone else. When it come to full time work, there is much more interest outside of amiga world, in compare with real Amigans, who even for money most of time do not want to do anything :)

@kas1e

How about, instead of a longshot of trying to persuade externals to work for this quite complicated task, we take the easy route and expand and improve the tools we have already?

Spotless is not perfect, but this is only because it has had very little testing and therefore does not take care of most specific use cases with completeness. It could quite easily be brushed over to take care of these, as soon as they are identified.

Also it already comes with an easy to understand ui, and on top of that it is extremely lightweight and AmigaOS specific, which makes it easy to expand to new features.

What do you think?

@alfkil
I think you are right, but, who will do that?:) I mean, realistically, it's only you working on spotless. If you have no time/motivation, things just stop, and nothing comes out of it. Once you have motivation, then things back on track. So it all depends on you )

Another issue, for debuggers: the ones we wrote, can't be that good as those ones written by hundreds of persons and tested by thousands. That kind of app is just too hard. Too hardcore.

GDB is a full mega combine of everything anyone may need for the latest 20 years. Remove debugging included (how long it will take once anyone can use Visual Studio with remote debugging to debug amiga apps? Probably never. But with GDB we can have that). Or how we can debug graphics drivers for real without remote debugging?

We, of course, can make our new one from scratch but we need someone who will do it, do it fast, every day, for a few years. Then yep. But surely no one will realistically.

I am fully for native, written from scratch apps of any kind. But.. It's just not really that we can compare it with thousands of developers and a gazillion of users. To write a good debugger, we need good tools, for which we need a good debugger :)

If you will/want to improve Spotlessly I am 100% up to any tests and help and so on :)

At the end of all, wrote a Reaction or MUI GUI for the GDB port, and it will be the same native app.

@kas1e

Maybe you are right - GDB has been developed over many years with a gazillian of contributions. But none of these are amiga-specific. So in any case there needs to be done an amazing amount of work on the amiga side.

Spotless is already mature enough, that it handles the basic cases. I have so far yet to receive a single bug report. Which probably means that no-one is using it or even trying to. The moment the reports and requests start comming in, I can start to work/comment/support.