Investigate the wosdb debugger

[rkujawa]

Frank Wille once wrote a WarpOS debugger called wosdb. Apparently it does everything with WarpOS API. Not sure if it would be useful for debugging sonnet.library itself, but definitely would help fixing applications running on top of it.

Investigate and make necessary adjustments to make it compatible with sonnet.library.

[DvdBoon]

Looking at the source of wosdb reveals functions still missing in the sonnet.library. All poolmem functions to begin with. These have to be implemented first. Then task exception functionality has to be build into the sonnet.library. This cannot be done before the implementation of a scheduler.

[rkujawa]

Some debug tool would be useful, but I think bringing wosdb as application-level debugged is not a high priority task. This can wait.

[DvdBoon]

As I run into more and more complex WarpOS programs (and bugs) i'm going to make the sonnet.library ready to be debugged by wosdb the coming weeks.

[rkujawa]

Okay! I'll import wosdb into separate CVS module.

[rkujawa]

Hmm, actually wosdb source license does not allow modification. I'll negotiate with Frank to change the license terms.

[DvdBoon]

Looking at a first glance at the source i'm not sure if it needs modification. Maybe to recognize hunk memory attributes.

First the following needs to be done at my end:

1. Set up the MMU using tables instead of BAT registers during initialization
2. Reimplement the SetExcMMU and ClearExcMMU functions
3. Add PoolPPC functions (Free, Create, Alloc, Delete)
4. Have a working SignalPPC implementation (which needs a scheduler)

After that I can see what is needed from Frank.

[DvdBoon]

Getting close to start testing with wosdb. Can you look at the source code and assess whether or not it needs adjustments regarding hunk recognition?

[rkujawa]

I think minor changes are necessary, although I admit that I didn't yet dig deep enough into wosdb source.

[rkujawa]

Frank Wille allowed for us to modify and release the source under following conditions:

With this mail, I, the author, give you the official permission to use the PPC disassembler and the WarpOS debugger (wosdb) source in your Sonnet project. I give you also the permission to modify the sources, but you have to mark everything modified with your name and that I take no responsibility for it.

[DvdBoon]

Haven't looked at it very recently, but I think it pre-loads the program before debuggig/executing. Which means it needs to recognize the special hunks (if it doesn't load it with LoadSeg)

[DvdBoon]

Having looked at the source of wosdb again it actually needs only the pool memory functions, signalling system and exception handler functions (SetExcHandler etc) in place. So this weekend I should be able to try to get it all working.

[rkujawa]

I wonder if we should make a separate repository for wosdb modifications? Or should the source just go into SonnetAmiga repo in a separate directory?

[rkujawa]

I decided to just import it into SonnetAmiga repository: af0f7a2 . Now that it's here, I'll see what's needed to plug it into our build system.

[DvdBoon]

After manually adjusting the executable to get in running on the sonnet (see issue regarding sonnetpatch) I got some first output of the program. Too bad it was only the version number and Frank's email address (and then it exits), which shouldn't have happened. Same thing happens with a variery of arguments (?, h etc.) so I am guessing a bug somewhere in the sonnet library :-). As the output is unexpected, I suspect Run68K at fault. The program itself is 99% PPC, it calls 68K functions to output.

[rkujawa]

The -h argument should just display Usage: " NAME " [-hv?] [file name] [arguments]. If even that didn't work, it means something basic is broken ;). Since even stdui.o is compiled as PPC code, I also suspect a problem with calling 68K side.

[rkujawa]

Also, when I plug wosdb into our build system, I intend to:

• Mark all code and data sections to be loaded into 0x1005 memory.
• Link against sonnet.library instead of WarpOS.

If I understand correctly, patching won't be necessary then.

I think our build system on the server doesn't have the necessary .h includes from WarpOS SDK though. Need to fix that too.

[DvdBoon]

You are correct. I also changed powerpc.library to sonnet.library and V15 to V1 in addition to the hunkheader changes. wosdb actually uses LoadSeg to load in executables so they should go automatically to the correct memory if the correct flags are set in the hunk header of those executables

[DvdBoon]

Exception handlers are a bit more complex than I thought. Working on the Program Exception now as a template for the others (also wosdb installs a handler here to capture the first run PPC task). Run68K debugging will follow afterwards.

[DvdBoon]

A little whoops. The output of wosdb is actually as it should be...mostly. It reacts correctly on -v -h and -? ( i just forgot to use the '-'......)
It exits before loading the to be debugged file, though.

[DvdBoon]

Looking at the source it quits when the AllocSignalPPC functions returns a negative number. It turns out that a bug in this function in the sonnet library causes the function to always give -1 as a result. Fixed it and now we get a wosdb> prompt. The help option from the prompt works. All other options crash. So onward to the next bug fix...

[rkujawa]

In other news, I looked at compiling the code directly for sonnet.library. But currently I have no idea how to produce a PPC object file with 0x1005 memory flag from C code. I think this needs a linker script and vlink extended to support this functionality (currently vlink can extract this information from .o where it is placed by vasm, but not from linker script). As usual, I'll talk with Frank about adding this.

[DvdBoon]

Got some output now. But the program crashes on SysBase->MemList.lh_Head which is a read from Amiga memory. Have to figure out how to circumvent this.

[DvdBoon]

[DvdBoon]

Whooptidoop.....

[rkujawa]

Sweet! Congratulations!

[DvdBoon]

There are still some minor issues, but these are also in the original WarpOS (e.g. intercepting or skipping function calls which wosdb uses itself too -> resulting in a hang).

[rkujawa]

I'd say this still needs plugging into our build system, so that we can have correct binary built (and improve upon the codebase in the future). I intend to do that ;).

[rkujawa]

Frank is going to add new features to vbcc to allow generating code with extended memory attributes set. Currently anything generated with vbcc still needs patching later. Once a new vbcc version is ready, we'll be able to build wosdb that works with sonnet.library out of the box.

[rkujawa]

The new source snapshot of vlink supports specifying attributes on the command line:
-hunkattr .text=0x12345678 -hunkattr .tocd=0x12345678

This way, at least in theory, we can build any WarpOS application from source, to be Sonnet-compatible, with minimal changes to the build process.

Will proceed to update toolchain on the server (soon 😛).

[rkujawa]

The wosdb is now built as a part of Makefile build process (done in c0086ea). Just the issue #30 left...

[rkujawa]

While here I updated PPC disassembler used by wosdb to the latest version ( commit 274a720).

[rkujawa]

@DvdBoon The wosdb executable from latest server build needs testing... 😃

[DvdBoon]

Tested it. Works correctly.Now I need to rebuild vlink, I guess :-)

[rkujawa]

Yes, just use latest source snapshot from Frank's site.

[DvdBoon]

I'm still not getting all 2005 hunks. Did I miss something?

[rkujawa]

Did you update the source? Did you clean .o from previous builds? Do you use Makefile to build it?

Note that in wosdb there are special sections hand-crafted in assembly, so VBCC config is not enough to link properly. Check out LDHUNKATTR variable in Makefile. I don't link using vc, but manually calling vlink.

[DvdBoon]

I made a clean directory with the newest vlink. Build it, manually changed the 2 hunks (the one with 4 and 6 Longs) placed it in the vbcc bin directory and deleted all the .o files again and also vlink in the build directory. Then rebuild, but the resulting binary still has the 2 hunks without $2005

[rkujawa]

Ah, so you are building vlink, not wosdb? This is wrong issue then 😄.

There 2 hunks are from what sections? Is it perhaps a case of missing -hunkattr .ctors=0x2005 -hunkattr .dtors=0x2005 ?

[DvdBoon]

D'oh!

2016-02-07 23:53 GMT+01:00 Radosław Kujawa notifications@github.com:

Ah, so you are building vlink, not wosdb? This is wrong issue then [image:
😄].

There 2 hunks are from what sections? Is it perhaps a case of missing -hunkattr
.ctors=0x2005 -hunkattr .dtors=0x2005 ?

—
Reply to this email directly or view it on GitHub
#9 (comment)
.

[DvdBoon]

Works perfectly now! :-D