Current state: binary can be built with newlib, it runs, you can load dwarf4 debug binaries, list them, set the breakpoint, but actual running does not work for now.
With older public GDB (which based on GDB 6.3a), we end up that x5000 GDB can't break and bring SIGBUG error while we tried to do so, while on pegasos2 we still can. On x5000 there are new debug facilities, not the same as on older g3/g4 CPUs so that can make a difference (if there no other issues involved: to be checked).
I asked Thomas about and he says that he thinks the debug facilities interrupt is present on the current x5000 kernel already, but it has never been tested and might not work at all.
The new CPUs also do no longer have the trace enable bit in MSR that was available in older versions, so an adaption to the debug interrupt is necessary. This is, unfortunately, not that straightforward anymore (if you have the Motorola EREF manual, check Chapter 9, it outlines the debug facilities).
So we need to check if things work at all.
I also tried morphos on x5000 with their GDB 8.3 port, and that works for sure. Everything works as expected.
Through, that point us to nowhere: it can be that morphos' kernel just has all things in place already for x5000. But from another side, we also can check morphos' diffs for gdb to see if there anything special for x5000 done.
Edited by kas1e on 2021/2/22 5:17:52 Edited by kas1e on 2021/3/4 18:01:30
Next, I got my new x1950 graphics card, and able to install the latest morphos and latest SDK on it (where they have GDB 8.3 port), and check if it can break/trace things: and it can. Everything works as expected.
Through, that point us to nowhere: it can be that morphos' kernel just has all things in place already for x5000. But from another side, we also can check morphos' diffs for gdb to see if there anything special for x5000 done.
I think it points us somewhere at least. Like you say, it probably works thanks to MorphOS itself, but it doesn't hurt to study the GDB patches. Was it Thomas that did the work on the current GDB?
Was it Thomas that did the work on the current GDB?
Back in times: yes. But after him land diffs to adtools repo, Sebastian do some changes on as well.
Thomas says he surely have no time to work on GDB for sure, but he can help us with all kind of technical info and help and necessary kernel tests/fixes, we just need to start somewhere.
For example, right now we probably need to check "is debug interrupt works on x5000 at all" the same as on peg2 for example.
On Morphos/x5000 GDB surely works as expected , see:
Quote:
Ram Disk:> gdb -q test Reading symbols from test... (gdb) list 1 #include <stdio.h> 2 int main() 3 { 4 printf("asdfasdfn"); 5 } (gdb) break 4 Breakpoint 1 at 0x7d8: file test.cpp, line 4. (gdb) r Starting program: /RAM/test [New Task 0x180c8530]
If i remember right Sebastian didn't move gdb to the github page (or move, but then deleted), as there were hope for db101 debugger to be improved futher,etc, but so far that was too optimistic, and GDB is one we need for sure (as other ppls from whole worlds develop it, we only need to "port" ).
I buld that versoin via latest gcc 10.0.2, and it have exactly the same issue as have SDK's version.
@sTix I give it a go and checked our 5.3 patches as well as adtool's repo code. In brief , its 3 "big" files implemented: elf32-amiga.c, solib-amigaos.c and amigaos-nat.c.
About other 15-20 files have very few changes. Sobjes support we also can disable at the moment all together with no probs imho (if that solib-amigaos.c mean sobjs).
I for now just tried to make working binary of 7.5.1 version (at least that version should be not that far from our 6.3 one, and it has dwarf4 support as far as i aware). So far that what i do:
Quote:
cd gdb-7.5.1 mkdir gdb-build cd gdb-build ../configure --host=ppc-amigaos --target=ppc-amigaos --build=x86_64 --disable-nls --disable-werror
--disable-werror needs it, so modern GCC does not fail on some part.
line 594: extern const bfd_target bfd_elf32_amiga_vec;
line 959: &bfd_el32_amiga_vec,
3. copy efl32-amiga.c from adtools's bfd directory to our one.
And at this point, it stops, as it needs proper integration (some undefs, some re-declarations, etc). But what it all means we already can use the way how patches for the 5.3 version and adtool's version done, and it can be done pretty fast by anyone having a few programming skills (not like me). I can continue slashing/hacking all things together, can make some repo where can fix simple things, etc if need it.
Maybe indeed let's start from 7.5.1 ? Once we have a working binary, we can continue further (if there will be needs, at all, maybe 7.5.1 will be more than enough for time being).
Yup, a repo will make this easier with all of the code in one place. I'm happy to help out with any programming that we need to do to get this working. Kas1e, can you create a repo with the 7.5.1 code with the needed patches in?
I will also try to get involved as much as I can, although I am not familiar with these stuff, but I want to learn and help wherever I can. Maybe we could build a small team for this project to work actively.
-- added the elf32-amiga.c file done by Thomas/Sebastian for our older ports, fully commented out, needs some adaptation work, but at least now it continues to builds futher. -- fixed libreadline.a build
So for now it builds all necessary for gdb internal libs and stops on configuring GDB itself saying "*** Gdb does not support native target powerpc-unknown-amigaos" , checking how to fix that
Edited by kas1e on 2021/2/19 13:45:44 Edited by kas1e on 2021/2/19 13:46:28
This is great, thanks Roman. I've checked out the repo and on Linux Mint 19.3, which is based on Ubuntu 18.04, and I am missing the termcap library which gives tgetent so I get to
checking for library containing waddstr... no
configure: WARNING: no enhanced curses library found; disabling TUI
checking for library containing tgetent... no
configure: error: no termcap library found
Makefile:8369: recipe for target 'configure-gdb' failed
make[1]: *** [configure-gdb] Error 1
make[1]: Leaving directory '/home/billy/Projects/amiga-gdb/gdb-7.5.1'
Makefile:843: recipe for target 'all' failed
make: *** [all] Error 2
Has your build got past this part? libncurses5-dev and readline-dev don't fix this for me so I'll download the termcap library from the GNU site and build and add it to this.
That with few more fixes, added some amigaos4 specific files from the old repo (with half disabled code to make it compiles). And it of course didn't work, it just executes "select: ." in a row automatically for some reasons, but binary ready and links. That probably the most annoying part was in which no one wants to dig in. Hope tomorrow to clean things and commit, so real programmers can join.
Also, I had to add --disable-sim, or by default, it starts to compile those simulators which we probably not need.
Also, I think at the beginning we can use --disable-shared too, and not worry about "sobjs" support: firstly we need to make working plain simple binaries.
Nice, full steam ahead as usual Having it on GitHub is a very good start. I'll try to get some time to look around a bit and see if I can contribute in some way.
1). necessary changes in configure scripts so things build 2). some small fixes to actually build it all 3). shared objects fully disabled (firstly we need basics works). 4). bfd/elf32-AmigaOS.c file added but fully commented, with simple placeholder function so things compile. Those ones are first which need adaptation to the new version of GDB. I tried yesterday, seems not hard, but need some programming skills. 5). Also added placeholder config "gdb/config/AmigaOS.mt", in which in old version were references to AmigaOS-nat.c ("nat" mean there Native-dependent code, so we have to deal with elf32-amiga and amiga-nat files). Currently, I didn't upload that file as we have already things to deal with.
Currently, as far as I see we need to fix the "gdb" terminal itself. That not related to missing amigaos-elf code support, but general porting issue: for now once you run it, it says "can't find the file" and start typing "select ."
Once that fixes and we can type commands in, we then can go further and adapt/fix the elf32-amigaos.c file to the new GDB.
So now, real programmers help need it. All boring annoying work is done, we just need some of us to clone the repo, build, and fix bit by bit.
Once we fix the terminal and then adapt elf32-amigaos file, and things start to works on peg2, etc, we can start to worry about x5000-trace-breakpoint functionality.
Imho nothing hard, just need some of your motivation
Awesome work! I can get it to build too now, I had to slightly tweak it to get it see the termcap library, but that is just down to where people have put it. So I used
I had to slightly tweak it to get it to see the termcap library, but that is just down to where people have put it. So I used
People should always install 3d party libs to the SDK, or if not, then yeah, they on their own if they choose to broke rulz :)
@All I also build the very latest 10.1 gdb: binary ready, but on running bring some other (new) issues. They can be fixed of course too, but the question is: do we need to concentrate on 10.1, which seems to start to use threads as well (where we may meet new issues and that will slow things down) and also, the size of the binary starts to be bigger: the stripped-down version is 10MB in size (while 7.5.1 is 6MB and version 6.3 is ~4MB). Not a big deal, of course, 10MB for the 2021 debugger is more than acceptable.
Now, the question is: do we need to deal with 7.5.1 at first?
I may for example in the GDB repo create another version that will be built out of the box, just without necessary specific os4-elf support (with dummy functions). Like now we have 7.5.1, but I can also make those ones:
7.12 8.3.1 9.2 10.1
But still, it all will be just empty builds, without elf32-amiga / os4-nat(Native-dependent code) support which needs to be adapted/re-implemented from our old version.
Glad to be a rule breaker I'm sure there are loads of changes but when I went from gdb 7.x up to 10.1, the only change I noticed was that font styles and colours were implemented for the source code when you are using gdb. Looking at the changelog, that was implemented in 8.3
For my use cases, which generally are load up a program and step through until it crashes, there wasn't any extra functionality that I needed from the later version. Gdb 10 feels a bit faster at parsing the symbols when debugging shared objects, but that was only really noticeable to me when debugging a Qt program. By the looks of the changelog, they did that by using threading. You have way more experience of threading issues on OS4 so you will have a better idea than me as to if that is a pain worth taking 🙂
So, for me personally, any version on OS4 would do other people might need the newer features, I just want a debugger that we can use 🙂
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
