Yes, I'm slightly interested (and slightly reluctant). IMO the major gaps right now are git (sgit seems to have halted?) and gdb.
Without native git, we at least can use cross-compiler's git, or even download from the web, but without native GDB with dwarf4 support, we can't debug os4 bins in realtime (even that patch about which I told before didn't help, because once you link binary building with dwarf2 but with all those stubs .a libs which build with dwarf4, GDB then still cry that this is dwarf4 and can't do shit with).
Quote:
Yes, I'm slightly interested (and slightly reluctant). IMO the major gaps right now are git (sgit seems to have halted?) and gdb.
As far as I see, gdb 8.3 on morphos use Binutils-2.33.1. Why exactly that one dunno, probably the author of gdb port just sticks to it for internal reasons, so I mean Binutils.
From another side, maybe it will be easier to add dwarf4 support to our current gdb version?
Btw, by core utils means what ones? Native versions of make, awk, bison, new python, Perl, sed, cp, cat, and all that ? If so, it also not of _that_ big problem, because again, it at least can be solved in some way by using cross-compiler, while without native GDB you can do shit in terms of debugging :) IMHO, native GDB is that which we need 100% and it really necessary, and not cross-compilers, not virtual machines can cover it at the moment.
Yes, I'm slightly interested (and slightly relectant). IMO the major gaps right now is git (sgit seems to have halted?) and gdb.
I started work on upgrading to the latest libgit2, and got it using AmiSSL rather than a static older version of OpenSSL, but I stopped when I hit the fact the it uses mmap () and munmap () now. I think there was only one or two instances where it was writing to a mmap'd buffer, the rest were just reading which is obviously easier to deal with. My build environment could use the older libgit2 or a newer one so I'm going to update the instructions on my forked repo as how to build the different versions and see if I can get the energy to have another crack at it. Anyone willing to help work on it would be very appreciated!
I didn't know this, but gcc 10 still supports dwarf 2 using the '-gdwarf-2' option. Using that, it's possible to load binaries using the gdb from the official SDK. Most things don't work though, I can inspect sources but break points don't work. When I tried it with the old compiler in the SDK it's the same thing. Is gdb in the SDK broken or am I missing something? I've tried both the stabs and the dwarf 2 format.
I didn't know this, but gcc 10 still supports dwarf 2 using the '-gdwarf-2' option. Using that, it's possible to load binaries using the gdb from the official SDK.
Yeah, but problem that most libs (those which on os4depot ones, any older local builds of developers, etc), build with more or less decent versions of GCC. And even if you build dwarf2 binary , but link it with those libs which were build as it (so dwarf4), GDB then says "dwarf4, sorry".
Quote:
Most things don't work though, I can inspect sources but break points don't work. When I tried it with the old compiler in the SDK it's the same thing. Is gdb in the SDK broken or am I missing something? I've tried both the stabs and the dwarf 2 formats.
Yeah, it has heavily broken as far as I can see now. On x5000 even if I just load the binary into, and do "break main", and then "r", it just didn't break on main, but exit instead.
I need to check if it works on peg2 at all now. And if is, then it mean x5000 specific (at least we have something of that sort with Alfkil when debug spotless and db101 until he loose motivation)
It would be good with a working baseline before someone (again, I don't want to point any fingers in my direction ) starts to work on a recent gdb. It's not fun to solve two problems at the same time.
Btw, by core utils means what ones? Native versions of make, awk, bison, new python, Perl, sed, cp, cat, and all that ? If so, it also not of _that_ big problem, because again, it at least can be solved in some way by using cross-compiler, while without native GDB you can do shit in terms of debugging :) IMHO, native GDB is that which we need 100% and it really necessary, and not cross-compilers, not virtual machines can cover it at the moment.
I started work on upgrading to the latest libgit2, and got it using AmiSSL rather than a static older version of OpenSSL, but I stopped when I hit the fact the it uses mmap () and munmap () now. I think there was only one or two instances where it was writing to a mmap'd buffer, the rest were just reading which is obviously easier to deal with. My build environment could use the older libgit2 or a newer one so I'm going to update the instructions on my forked repo as how to build the different versions and see if I can get the energy to have another crack at it.
Nice. But the mmap and munmap problem shouldn't be too hard if the mapped file fits into memory (thanks to the Amiga way of managing memory). I might overlook something, but isn't it just mmap -> read the whole file into a buffer, munmap -> write buffer to file?
Quote:
Anyone willing to help work on it would be very appreciated!
Is gdb in the SDK broken or am I missing something? I've tried both the stabs and the dwarf 2 formats.
Tried the same GDB on pegasos2 and on x5000. On pegasos2 tracing/breakpoints works, on X5000 didn't.
So as peg2 is G4, but x5000 are not and mean to be "embedded kind" in means their debugging facilities are different too. X5000 CPU has a special debug interrupt, but this one is different from the trace interrupt in G4. This means that needs to be taken into account when making tracing/breakpoint works on x5000.
In other words, it means some x5000 specific code probably.
Tried the same GDB on pegasos2 and on x5000. On pegasos2 tracing/breakpoints works, on X5000 didn't.
So as peg2 is G4, but x5000 are not and mean to be "embedded kind" in means their debugging facilities are different too. X5000 CPU has a special debug interrupt, but this one is different from the trace interrupt in G4. This means that needs to be taken into account when making tracing/breakpoint works on x5000.
In other words, it means some x5000 specific code probably.
Excellent, then it works, sort of. The neccessary changes should be out there somewhere I guess. Whoever is doing an embedded application with this CPU ought to have what we're looking for.
Excellent, then it works, sort of. The neccessary changes should be out there somewhere I guess. Whoever is doing an embedded application with this CPU ought to have what we're looking for.
When I ask Thomas about it half of year ago, he says "They have a special debug interrupt that is completely different from the trace interrupt in previous architectures. The facilities themselves do exist, but you have to write special code for it." He wasn't sure at this time if the debug interrupt routes over the TRAP exception handler at all, but he doesn't think there is any way to discern which one it is. But from that discussion come this enhancement request: https://execsg.solie.ca/mantis/view.php?id=52
This is done with the comment "Debug interrupt can now be accessed via TRAPNUM_TRACE (this more or less ties in with previous incarnations of the facilities)". So, we just need to test it all if it works, etc.
EDIT:
I also think we may have some issues with "alignment" : on x5000 CPU, as it misses 4 opcodes (lfs, lfsu, stfs, stfsu). without which we always need to align the data/code, etc. That can be another reason why old gdb didn't work on x5000 too.
This is pretty sure not a genuine crash of gcc9/10 but probably a long standing one. (Haven't tested with anything else than gcc10.1.0)
If i set the stack of WB shell to the lowest possible (65528) and try to compile my project, i *always* get a very hard crash with no grimreaper coming up and only rudimentary output on serial.
kernel 54.30 (1.1.2021) AmigaOne X1000 release
Machine model: 6 (AmigaOne X1000)
Dump of context at 0xDF9593E0
Trap type: DSI exception
DSISR: 42000000 DAR: 54DD0FF0
Page: 0xDF9672A0 (Virtual: 0x54DD0000, Physical: 0x00000000, Flags: 0x 800)
Machine State (raw): 0x100000000000B030
Machine State (verbose): [Hyper] [ExtInt on] [Super] [IAT on] [DAT on]
Instruction pointer: in module kernel+0x00050668 (0x02050668)
Crashed process: gmake (0x5336A9C0)
DSI verbose error description: Access to address 0x54DD0FF0 not found in hash or BAT (page fault)
Access was a store operation
0: 0204BCBC 54DD1010 07F7FF00 02B216A4 DF8E6D98 00000003 00000000 6FF78068
8: 00000003 02B20000 6FF78068 00000003 93933393 FE00090E 00000000 00000000
16: 00001000 00000000 00000000 DF953F60 00000000 00000080 00000000 00001000
24: 0000004F 6FF78000 0000000E 00000003 0000000F 00000004 00000024 DF8E6D98
CR: 53933393 XER: C0000000 CTR: 02031C68 LR: 0204CAE0
Yes, gcc needs a lot of stack. A stack cookie is a good idea if there isn't one there already (I haven't looked but I'll do that tonight). But picking a good value is less straight forward than for a 'normal' application since it depends on what source code you're working with of course. Perhaps we should just give it 'a lot', 10M or so. A more ambitious approach would be to pick a big project (let's say kas1es OWB) and use Valgrind (Massif) to get a real measurement and add some on top of that.
Its gmake that crashes and it doesn't matter what source file, it will crash as soon as gmake is invoked.
I have a big project (scummvm) here and am just trying with 500kb of stack, which doesnt throw any errors upto now.
Before that I had the shell set to 2 mb, but I thought that must be overkill, so I went on to see what happens if I drain the stack...well, not that good idea of an idea.
I was also a bit to quick Gmake is not a part of adtools so if we want to fix that we need to do it elsewhere. But it's not really critical, I guess most people have a decent stacksize nowadays.
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
