November 23, 2007

Find a bug...

in the following piece of code:

/* Allocate method table for this interface */
ifb->MethodTable = (struct IFMethod *)AllocVec(mtab_size, MEMF_ANY);
if (ifb->MethodTable)
{
  /* Get correct ID for the interface
     (string ID => interface ID mapping) */
  if (init_mi_methodbase(interface_id, &(ifb->InterfaceID), OOPBase))
  {
    ....

Found it? No? Too bad, you loose. Remember my words: "ULONG is BAD, IPTR is GOOD". The init_mi_methodbase expects as a second argument a pointer to an ULONG and the ifb->InterfaceID was declared as an ULONG some days ago. It was supposed to work properly, since the ID is not a pointer in any form. Fine. The issue is, the struct IFMethod which did contained the InterfaceID ULONG field "inherits" from the Bucket used in hahstables of the oop.library. The Bucket structure expets this ID field to be an IPTR....

What a mess!

The 32-bit ULONG variable of struct IFBucket was initialized properly but the Bucket structure expected to find there a 64-bit IPTR one. Until now it was just reading some random values, name them trash. On some machines one had there zeroes instead of random values. That was the case on my machine, on qemu and on vmware. I have not seen this bug :) Now I have modified memory alloc functions, so that they fill allocated region with some trash, unless the MEMF_CLEAR flag was set. Thanks to this small change I was able to see what many of you saw upon trying my last aros64 iso. After some fight with oop.library (adding debug points here and there) I have solved the issue.

You may download the new AROS64 iso from here. The md5 sum of the file is: 4852e85ab83f949e9ffe0019ea039e59.

I hope you will be able to boot into Wanderer now. And remember, AROS64 in VESA mode looks simply better :)

EDIT: I have uploaded newer iso. Here, the kernel limits address space to the 4GB. As soon as proper MMU handling is done, I will remove this limit.

November 20, 2007

AROS x86_64 Beta 2

Don't expect much from it. It is a beta 2 in early test phase - many things may just crash without any warning :)

Anyway, you may get it from here.

Awful bug...

(~0UL/2+1)....

What's that, you will ask? Well, that was TEH BUG which made all buffered dos operations (the ones done through FGetC, FGetS, FPutC, FPutS, Printf and many more) unusable on x86_64 target. What does this line? Well, it should set the highest bit to one and clear all other ones. This tiny line of code works perfectly... Better than enyone expected in the old times, where C's long was 32-bit...

The struct FileHandle of dos.library contains a tiny buffer used to speed up file operations. The buffer could be therefore in both READ and WRITE modes. In order to set it into write mode, the FHF_WRITE on the filehandle's flags has to be set. The fh_Flags field is of type ULONG - it is a 32-bit unsigned number.

The FHF_WRITE was defined as ~0UL/2+1. Fine. On x86, where the type long is 32-bit, the FHF_WRITE equalled 0x80000000. On x86_64 however the type long is 64-bit wide. The FHF_WRITE flags was therefore 0x8000000000000000. And this value does not fit into ULONG variable......

I have redefined the FHF_WRITE variable a bit and suddenly the buffered operations do work, as you may see on the screenshot (yes, the whole shell uses buffered operations :-))). Finally, after one month of useless fight I continue on the x86_64 port. Sweeet.

Labels: ,