fresh version of GDB for test

@all

After few tryes to use latest version of GDB (this one which flyes arond topics there, and which was crashy and buggy at some first-little tests), i with BIG help of Sebastian Bauer manage to setup cygwin/cross-compiler environment, and build latest GCC and latest GDB , in which (in boch) was done some changes by Sebastien since latest public SDK (also changes done by Alfkil in GDB are there too). While GCC and all the stuff its up to Hyperion to release with new SDKs and so on, the new version of GDB can be interesting for developers to use it right now. That build are "clib2" build , but i will try also build "newlib" one in next days (that can make sense in stability as well).

That release of course have problems, and can be buggy, but at last you can load binary , set breakpoint at the main , start the project and disas the functions from the binary.

Download it here.

Sebastian pretty busy at moment with other stuff, but lets collect all the bugs and problems here, because it will be easy later to fix them,

@kas1e

@kas1e

Cool! It will be nice to have both a "native" debugger as well as the popular GDB for programmers used to that.

@all

Thanks to kas1e and sba for working together on GDB.

kas1e, do you have thinked to help sba on valgrind port ???
(yes, I know you help a lot amigaOS with all your work and port on the machine and I'm annoyed a lot to write that).

@billt
Quote:
Yep, i think the same, more the better.

@Mrodfr
Its all done by SBA (+ alfkil fixes) for now, i do nothing there.. When someone will points on bugs about GDB in that topic, i hope i can try to fix easy ones :)

About Valgrind: If SBA will start to works on it again, i will help with as i can of course. He a bit busy for now with other stuff.

Trying to build "newlib" version of GDB, and while it builds now , and runs, i have some strange error when GDB trying to handle aos4 executable.

Quote:

Anyone familiar with such problems maybe ? It is possible that clib2 and newlib have different seek() implementations which can cause that bugs ?

@kas1e

I know that It's not a tool for me because I'm not a C developer but I'm curious and would like to know what look like gdb

what is the use of this strange button on grim reaper !


I have installed SDK, but the minimal installation, and replaced the old gdb by the new one.

Have launched a tool that crash and gdb was unable to found something at $xxxxxxxx.

After I have launched another tool and a DSI and another tool and a DSI. Apparently, the use of GDB crash tool after the use of GDB.


I'm not the good guy for this tool but I'm curious to know if this tool could help a programmer who do cross compiling with cygwin enviroment to found the errors on AOS4 by sending to him GDB outputs.

also help work but stack command not work (same for some other commands) ?

@kas1e

gdb nzbget

give a DSI:

Crash log for task "gdb"
Generated by GrimReaper 53.2
Crash occured in module elf.library.kmod at address 0x015320F8
Type of crash: DSI (Data Storage Interrupt) exception

Register dump:
GPR (General Purpose Registers):
0: 0001656C 59E347C0 00000000 0100DE54 01529FEC 01503924 01503924 00000000
8: 008C0000 0000000C 008C0000 014154A8 24424048 00000000 5A8F4BC8 59E40000
16: 59E348D8 5AD0D3E0 5A8F4B40 01CA97C4 00000000 5A01C4A0 80000001 59E3FBE0
24: 59E40000 59E34818 00000000 80000001 00000000 5AD0D3E0 0152B6F4 5A01CAC0


FPR (Floating Point Registers, NaN = Not a Number):
0: nan 2.11725e+214 1.18795e+190 3.29513e+180
4: 1.16106e-72 2.69823e+78 7.05954e+64 1.96185e+247
8: 4.25323e+174 1.0296e-71 1.20586e-71 1.97412e+26
12: 5.73688e+228 9.80175e-72 0 0
16: 0 0 0 0
20: 0 0 0 0
24: 0 0 0 0
28: 0 0 1.61029e-231 0

FPSCR (Floating Point Status and Control Register): 0x82000000


SPRs (Special Purpose Registers):
Machine State (msr) : 0x0002F030
Condition (cr) : 0x44424042
Instruction Pointer (ip) : 0x015320F8
Xtended Exception (xer) : 0x20000003
Count (ctr) : 0x014154A8
Link (lr) : 0x015320F0
DSI Status (dsisr) : 0x00000000
Data Address (dar) : 0x00000008



680x0 emulated registers:
DATA: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
FPU0: 0 0 0 0
FPU4: 0 0 0 0



Symbol info:
Instruction pointer 0x015320F8 belongs to module "elf.library.kmod" (HUNK/Kickstart)

Stack trace:
native kernel module elf.library.kmod+0x000081f8
native kernel module elf.library.kmod+0x000026e8
native kernel module elf.library.kmod+0x000061f4
module gdb at 0x6F725C28 (section 5 @ 0x21C08)
module gdb at 0x6F725F00 (section 5 @ 0x21EE0)
module gdb at 0x6F70B808 (section 5 @ 0x77E8)
module gdb at 0x6F710190 (section 5 @ 0xC170)
module gdb at 0x6F70EB44 (section 5 @ 0xAB24)
module gdb at 0x6F710BD8 (section 5 @ 0xCBB8)
module gdb at 0x6F710C28 (section 5 @ 0xCC08)
module gdb at 0x6F710CE0 (section 5 @ 0xCCC0)
module gdb at 0x6F704C5C (section 5 @ 0xC3C)
module gdb at 0x6F70EB44 (section 5 @ 0xAB24)
module gdb at 0x6F710BD8 (section 5 @ 0xCBB8)
module gdb at 0x6F710C28 (section 5 @ 0xCC08)
module gdb at 0x6F7041DC (section 5 @ 0x1BC)
module gdb at 0x6F704198 (section 5 @ 0x178)
module gdb at 0x6F8DAF30 (section 5 @ 0x1D6F10)
module gdb at 0x6F8DB3B0 (section 5 @ 0x1D7390)
native kernel module dos.library.kmod+0x0001b524
native kernel module kernel+0x00036290
native kernel module kernel+0x00036310


PPC disassembly:
015320f0: 813d0024 lwz r9,36(r29)
015320f4: 801f0030 lwz r0,48(r31)
*015320f8: 817c0008 lwz r11,8(r28)
015320fc: 7c004b96 divwu r0,r0,r9
01532100: 935c0004 stw r26,4(r28)


And If I use attatch to GDB:

GNU gdb 6.3 (AmigaOS build 20050719)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "ppc-amigaos".
Reading symbols from WORKBENCH:SDK/C/gdb...(no debugging symbols found)...done.
0x00000000 in ?? ()
(gdb)


But If I do the same with another tool, I haven't crash. My example is compiler on cross-compiler on Linuxbox and also I have just the minimal SDK installed with your GDB.

Kas1e, do you have a more recent GDB somewhere ?

EDIT:

Hum, as db101 also crash with the same example, maybe the example is wrong or the elf.library.kmod (update2 one) not work also with gdb ? (I know elf.library.kmod from update2 not work well with db101).

EDIT2:

hum, copied elf.library.kmod from update1 to the amiga and make a cold reboot. same test and same DSI.

EDIT3: removed some ?

Thanks.

@Mrodfr

...(no debugging symbols found)...

Only programs compiled whit -ggdb option will have symbols.

Gdb enables developers to set break points and step in to machine code, it can track variables too.

Under linux I used strace it worked fine for me as long as there where no forks in the code.

@kas1e

This is great work, hope your interest doesn't deminish!

I remember I used to compile alot of mud codebases with -ggdb because circlemud always crashed at some point, of course I could never get gdb to do anything useful but I felt like I was trying ;)

We narrowed it down to possibly an incompatiable wait() but it was never explored fully to actually determine this exactly... anyway, that is way off topic...

Perhaps when I actually need to use this tool it'll be even more ironed out and for that I'm grateful!

cheers!

@kas1e

Thanks for the build !

I was wondering if there's any gdbserver build available somewhere... ?

Anyone got a download link?

Simon

@LiveForIt

Quote:

It is better to use -gtsabs insted of -ggdb on AmigaOS4

To avoid confusion, afx did a typo. That should be -gstabs.

ops.. yes. ;)

@Rigo

First Post

Yes, I found it eventually, I've made it a bit more obvious now :)

Simon