@All Thanks to MightyMax who working hard on bringing us updated and new GDB and AfxGroup (Andrea) who working tireless on clib4 all the time (which GDB uses now) we seems to hit some line where things start to working ! There is screenshot of actual updated GDB session on my x5000 (hit open image in new tab for fullsize):
Thanks for the link. Would this fix the elf32ppc emulation bug in current bintils? I'll download and test.
Good to see work put into GDB. Would this include the GDB GUI? I suppose that may be too much to ask given GDB hasn't worked for decades. A console GUI also looks like a DOS or Linux thing so it's not exactly an Amiga thing. But it would be good to have some kind of GUI like that of MonAm.
Thanks for the link. Would this fix the elf32ppc emulation bug in current bintils? I'll download and test.
Never heard about that, but If you give me a test case, I will take it into account for during further development.
I don't know if the GUI of the gdb will work, but a major goal will be that the "-mii"? options work for local integration into IDEs/Editors/Wahtever and later on even the gdbserver.
IMHO gui is not the problem we need to worry about, firstly basics should works and be bug free, IMHO :)
Then, there also inbuild kind of "temrinal gui" into GDB which one can spawn by running "gdb -tui", and it will use ncurses/pdcurses/whatever to have semi-terminal-gui, like i do before with older gdb , see in this post:
There i use PDCurses working over SDL2 , which give me issues and bugs there and there , so, if we will have (or we already have?) properly ported NCurses via Clib4, then this one can be used without SDL, etc and we can have something in terms of GUI.
But if one need fullblown gui, with reaction interface, all the tasty amigaos4 gadgets and co, then it surely lot of work to do, and can be done by anyone else knowing reaction based coding : gdb giving an API for, and provide a libgdb.a library which can be used from such a GUI easy, but that is really another story, we can be at least in hope to have pure terminal version to work more or less, and maybe with remote debugging (someday), and that already will be awesome.
Never heard about that, but If you give me a test case, I will take it into account for during further development.
It can be caused by specifying it like this below. The first two examples demonstrate elf32ppc emulation failing. The last demonstrates the OS4 amigaos emulation working.
5.WorkbenchFE:C> ld -m elf32ppc -N
ld: cannot open linker script file ldscripts/elf32ppc.xbn: No such device or address
5.WorkbenchFE:C> ld -m elf32ppc
ld: cannot open linker script file ldscripts/elf32ppc.xc: No such device or address
5.WorkbenchFE:C> ld -m amigaos
ld: no input files
Quote:
I don't know if the GUI of the gdb will work, but a major goal will be that the "-mii"? options work for local integration into IDEs/Editors/Wahtever and later on even the gdbserver.
I've noticed in the O4 build that they lack the -tui- option.
There i use PDCurses working over SDL2 , which give me issues and bugs there and there , so, if we will have (or we already have?) properly ported NCurses via Clib4, then this one can be used without SDL, etc and we can have something in terms of GUI.
Great start. Yeah, I should have been more clear, I meant the GDB TUI. Which I haven't seen in any OS4 version of GDB. SDL would complicate it and since it's intended for console, not a game, needing SDL seems overkill and not the Amiga way of doing it. It's been a while but I'm sure NCurses was one I tested years ago. At least, when I was playing with MoL, trying to port it to OS4. Don't see any others but PDCurses on the Depot though.
Quote:
But if one need fullblown gui, with reaction interface, all the tasty amigaos4 gadgets and co, then it surely lot of work to do, and can be done by anyone else knowing reaction based coding : gdb giving an API for, and provide a libgdb.a library which can be used from such a GUI easy, but that is really another story, we can be at least in hope to have pure terminal version to work more or less, and maybe with remote debugging (someday), and that already will be awesome.
A ReAction GUI is definitely out of scope for a GDB port. I agree remote debugging would be awesome as it open up possibilities. Also being able to use a gdb server would be beneficial as well. If a server could be compiled in then perhaps a full gdb running on a remote machine would provide superior debugging with a full GUI. Possibly even a VSCode session could debug OS4 code over the network. A crash or freeze could be located more easily.
What would be good, though an obscure example, would be ability to debug firmware code. Say when testing client code running direct in UBoot or CFE. A crash that core dumps over serial is cryptic and not very helpful. However, being able to single step live, and catch the bad line would be helpful,
I've noticed in the O4 build that they lack the -tui- option.
Back then there wasnt proper ncurses/etc implementation, so gdb's configure didnt build support for in which result in missing -tui option.
I tried PDcurses which use sdl for my gdb builds and -tui works, just with bugs (and yeah, using sdl there just too much). Now, when clib4 seems have proper (dunno how proper is, didnt tested) ncurses port, we can try to use it too (and can be good test case for ncurses itself)
Here my test for the binutils 2.40 (inkl typo ) Seems to work!?
Yes! Confirmed. I tested the command in my current SDK and it works fine. For some reason the current ld command doesn't see the xbn or xc files which exist in the expected place. Youre build does.
I wouldn't say so yet. As it's a first working release. In the least I think it would be best to have it set up in a test SDK. I tested it from RAM. Being able to reassign SDK to use it on the fly would be useful.
@Raziel Hypex cant know it as he didnt work on, but saying obvious: to consider it stable or not, one install it, compile few personal projects and if it works, then it stable enough. After that bug hunting as usual if things go wrong anywhere.
I use it for last year probably and it works as expected for me
I think it is quit stable. I tried to document the needed changes to have a working binutils for ppc-amigaos. The most adaption are of minor kind. Where you might run into trouble is if you use baserel addressing mode. So if your project use that, please test binutils with your project and report back.
@Raziel Yeah, that one latest (through build with newlib, not clib4, which probably worth to recompile soon): it works and no bugs found, so no updates were done. Through your error with scummvm you had mean still to be there then. I probably should try to build scummvm with sobjs myself to see if i had same issue..
Your use for the last year, is this with publicly available versions of the OS / SDK, etc.? Or with beta versions? Only asking because if I recall you are also a beta tester - of course I also know you have more than one machine / install
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
) Seems to work!?
