Debug 101 (v.0.9)

@sba

Yes, of course. You have my permission to add the existing code to adtools if you want.

@Hans

and make that API an arexx port too

@JosDuchIt

One arexx port comming up...

@alfkil

New version of db101 has been uploaded. See original post.

@alfkil

first test (don't worry

Hum, Just remember that testing on AOS4.1U2 not work fine.
Verry sorry......

Just for curiosity


Executable section (0x1000074/3760392 bytes) starts at 0x6efef020
Relocating section ".stab" (index 23) which is referred by section ".rela.stab" (index 24)

and a DSI:

Crash log for task "db101"
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 5975C5B0 00000000 00E41D3C 01529FEC 01503924 01503924 00000000
8: 00B30000 0000000C 00B30000 014154A8 24002048 5995D8B0 00000000 5A8C3EBC
16: 58B9A22C 58E7BBE0 5B454680 01CA97C4 00000000 58E7C940 58B97344 5A8C31D4
24: 5B454680 5975C608 00000000 80000001 00000000 58E7BBE0 0152B6F4 59669C40


FPR (Floating Point Registers, NaN = Not a Number):
0: nan 2.45825e+24 1.64779e+93 3.15834e+231
4: 3.91208e+107 1.06281e+94 9.92552e+170 7.51825e+199
8: 3.15637e+21 4.91013e+252 2.16225e-307 1.26282e+200
12: 6.97271e+228 1.75792e+199 0 0
16: 0 0 0 0
20: 0 0 0 0
24: 0 0 0 0
28: 1.04023e-162 0 0 0

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


SPRs (Special Purpose Registers):
Machine State (msr) : 0x0002F030
Condition (cr) : 0x44002042
Instruction Pointer (ip) : 0x015320F8
Xtended Exception (xer) : 0x20000008
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
db101:amigaos_relocate_elfhandle()+0x384 (section 1 @ 0x914)
db101:load_inferior()+0x47C (section 1 @ 0xe14)
db101:gui()+0x1260 (section 1 @ 0x3a90)
db101:main()+0x24 (section 1 @ 0x1608)
native kernel module newlib.library.kmod+0x00001f4c
native kernel module newlib.library.kmod+0x00002be0
native kernel module newlib.library.kmod+0x00002d5c
db101:_start()+0x170 (section 1 @ 0x170)
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)

@alfkil

Nice ! But it pretty unposible to do more or less good tests because of that elf.kmod bug :( Maybe you can include working verstion of elf.kmod to archive ?

Anyway, what i can test before i get a lockup : windowses lock the main window. I.e. you spawn register-info window, and you cant press on breakpoint for example (but when you close register window, then breakpoints auto-pressed). The same for hexviewer.

Good progress all in all :)

@kas1e

Yes, I need to redesign the user-interface once I've added all the features.

@alfkil

Hehe, coding is like playing Myst: You have to look in the woods for the right code that opens the Vault etc...

I have uploaded a fresh version of db101 with just a few small additions. There are still many things on my list to do (like an arexx port and stack traces), but at this point I feel I need some feedback and a little motivation to go on. Is it possible, that someone could get out their old original OS 4.1 installation CD-ROM and fetch the elf.library.kmod from there so they can test my software? I know it's bothersome, but it would really help me quite a lot with some constructive user-insight.

Hope you enjoy!

@alfkil

Changing only elf.library.kmod give you DSI on IPREFS on start, and you need to change IPREFS on the old one too. After that, system itself a bit unstable (i.e. for example pressing in Filer on db101.lha for unpacking, give you DSI), but unpacking from shell are works.

So, i run it, choice hello word. It loads, say few words about some sections, then i press start. Then again choice load hello word, again start. Then i press "x" button. Then load of hello word third time, and press "breakpoint" - and on that stage window are spawns, and everything lockups. Soft reboot are works, and by dumpdebugbuffer i see nothing.

After that i do reboot, trying to load hello word again, but at this moment i just press "breakpoint" after i select file. And it spawn me window, with fucked symbols, which make me think, that changing on old elf.library.kmod not help much. There is how it looks like:



And after it again lockup.

I have many ideas which can be interesting for you, but firstly need somehow to make works what we have already :)

Check PM plz

@kas1e

Ok great, that's the kind of information I need 8-D.

I think the explanation is this: There was a quickfix uploaded btw the plain v4.1 and Update 1, and I think I'm using the elf.library from that version. Currently this seems to be the only working version apart from the latest (unreleased) version.

I guess we just have to be patient and wait for a new quickfix...

Thanks kas1e for taking the trouble, I really appreciate it

@alfkil

If i remember right, it was like this:
aos4.1
quick fix update
update1
update2

right ? I trying to use right now elf.library.kmod from the quick fix update for now : the same lockup on the breakpoint window. Maybe for you works that one from update1 ?

ps. Imho, for now you can redesign UI, just because for now its not too late :) because when you will add more and more feaures over "lockup the windowses" UI, it will be harder to rewrite it later.

@kas1e

Yeah, you are right, that's a good idea. I'll see what I can do, but as you know, this is my very first reaction app, and I'm a little weary about things still.

It is very strange, that the quickfix version gives you lockups. Here on my sam everything works just fine. Are you using a pegasos or amigaone? Are you using the latest upload from my dropbox?

@kas1e

Hehe, it turned out, that there was a big fat ugly bug in my breakpoint window, and I'm pretty amazed that I could go on for so long without knowing.

You should try a new download and see, if things are better now. Remember, if you want to debug anything else than "helloworld" you should use gcc -gstabs.

@alfkil
Tryed new version:

with elf.library.kmod from quickfix : run, select hello word, and pressing ok five DSI by memguard

with elf.library.kmod from update2(current one) : run, select hellow word, and pressing ok DSI with GR, GR stack trace:
Quote:

addr2line say:
Quote:

And gui.c at line 492
Quote:

If i comment out these strings, and recompile the debuger, and put elf.library.kmod from quickfix: then it runs, i can load the hello word, and set break button are works, and window not locks. Then i press: HexView button, browse it a bit. Close. Then i press Registers window, close, and have GR:
Stack Trace:

Quote:

Then again addr2line (on hex_free_section_list):

Quote:

And hexview.c at line 95 are:
Quote:

commenting out of these strings did the trick (of course memory will not freed, but who cares for testing-purposes).

So, there is 2 bugs for now: arguments checking and free memory in hexviewer.

@alfkil

Now when i do these 2 ugly "fix" to make debuger works fine, i test it more or less normally for now. And should to say: its indeed almost debugger already ! Of course there is still some missing information (like for example, when you press disassemble, you have just disassembled block, but, without references in which fucntion it. I mean (imho), when you press disasseble, will be cool if it will have in head that C source line, of which we have disassembled part.

Also i noticed, than in Hex Viewer, all the data a bit "unbound". It looks like this:



Will be good if it can have "good border canvas" (that will be easy for developers eyes to do brief views).

Also for now noticed that problem with "blocking windowses UI" : for example you set breakpoint, press start, then few steps, then, you press disasseble window, and then, you want to press "step" again, to see, how disasseble data are changes, but you cant. That a bid bad imho.

Also one more minus for "blocking windowses UI", its that for example, usually developers want to have register-info window all the time, and see in realtimve have it changes.

So (only imho of course), you need to redesign it to non-blocking windowses at this point, just to avoid problems in future :)

All in all its nice already, i think i already will use it for some stuff today (and then, can give more feadbacks).

Thanks for :)

@alfkil
Found two more bugs: Trying to load "a.out" file (from src directory), it loads ok, then pressing on SetBreak, give GR, with stackpoint:
Quote:

The same if i for testing purposes trying to load "Filer" binary. The same loads fine, and pressing on BP button give the same GR.

addr2line on such stack trace point on "stabs.c:103", which are:
Quote:
I think you not check there something on "if not present, then" ? (not exactly there, but early, at moment of loading).

Second one about loading of non-pcc binary. It sasy in the shell that "its not ppc binary", and then crashes (because i think it not exits correctly at this point?)

@kas1e

Quote:

Judging from the screenshot that Hex Viewer really needs to use a non-proportial (fixed width) font. The "System default" font should be OK for this purpose as it's guaranteed to not be proportional.

@salass00

EDIT: Problem solved, needed "courier.font" instead...

For now, I'm just using system default, which seems to be NOT non-proportional.

I've tried this:

Quote:

but it doesn't work. Could someone provide a simple tangible example of how to successfully load the courier font??

Fresh version of db101 uploaded. See original post.

@alfkil

Quote:

No, you're not. System default font can be found in GfxBase:


DateTime.docky defaults to this font and it is non-proportional.