[alliance] Status update

[vhandel@chem.vu.nl (Ramon van Handel)]

I've been doing a lot of CK work since the last changes but I have delayed
uploading it because it was not completely ready yet.  It still isn't completely
ready, but almost.  I decided to upload what I have done already so that people
who look at the code don't look at outdated code :)

I've been working on two things:

1.  I've almost completed the whole section on the system object manager on
    my TODO list.
2.  I've been implementing GDB remote debugging for the CK

The system object management changes changed a lot of fundamental things in
the CK (involving changes in over 50 file !)   Basically, all critical
information is now stored in CK memory, so that no security hazards can
occur and no difficult paging tricks need to be employed in order to access
object contents.  This has resulted in a lot of cleaner code.  Basically,
every object and resource structure now has two versions, a kernel version
(in CK/include/ckobjects.h and CK/include/ckresource.h) and a user version
(in CK/include/objects.h and CK/include/resource.h).  The user versions are
used for loading and writeback, and in some cases (thread objects) runtime
information.  The kernel objects are created when you cache objects and
are used internally inside the CK.
Basically, everything now works correctly except one thing:  these is
still a little bug in the shared memory code.  I will fix that soon.
For the rest, this part of my TODO list is more or less finished, I just
still need to clean up some of the structures and comments.

GDB remote debugging also almost works.  This is a great step forward,
because it'll allow much more efficient debugging of the CK.  Traditionally
remote debugging works over a nullmodem cable, but as I don't have access
to one of those (anyway, I'd have to unplug my mouse and modem aaarrgghh !)
I've written communication stubs for use over a parallel communication cable
(also known as a LapLink cable.)  GDB doesn't support this out of the box,
so I have patched GDB.  If you want to do remote debugging over a LapLink
cable you'll have to recompile GDB.  Here is the relevant piece of text from
CK/monitor/README:

------------------------

Remote debugging over the parallel port with GDB:

I hacked this together because I didn't want to use the serial port
for debugging.  Interfacing with the parallel port is rather more
difficult than interfacing with the serial port, because we have to
do buffering and handshaking in software (and that is *fraught* with
race conditions, believe me :)).  It should work, but if you experience
weird results (corrupt packets, stuff like that) you should try to
increase the DELAY values in dbg-par.c and ser-lpt.c.

How to recompile GDB with parallel port support:  this works for
GDB version 4.16, probably for other versions as well but I can't
promise that.  Copy the file ser-lpt.c into the gdb-4.16/gdb
directory.  Then edit the file gdb-4.16/gdb/config/i386/linux.mh
and change the line

    XDEPFILES= ser-tcp.o

to

    XDEPFILES= ser-tcp.o ser-lpt.o

Now edit the file gdb-4.16/gdb/Makefile.in and insert the following
line somewhere in the middle (use your intuition :)):

    ser-lpt.o: ser-lpt.c $(defs_h) serial.h

Now you can run ./configure and make in the gdb-4.16/ directory,
and you'll get a parallel-ready copy of GDB in the gdb-4.16/gdb/
directory.

How to do remote debugging over the parallel port with GDB:  follow
the following steps.

    1.  Figure out what the parallel port is on the host and target
        machine.  The following port numbers apply:

            PPort     GDB Name     I/O Data Port
            0         lpt1         0x3bc
            1         lpt2         0x378
            2         lpt3         0x278

        In my setup, the target machine's parallel port is lpt1
        and the host machine's parallel port is lpt2, so I'll
        use that as an example.

    2.  Edit CK/monitor/dbg-par.c, and set the define parport
        equal to your target machine PPort number.  In my case:

            #define parport  0

    3.  Compile the CK using the scripts/compile-ck script

    4.  Start the CK on the target machine.  It'll halt on boot
        with a "please initiate remote GDB" message.

    5.  Start the version of GDB you compiled with parallel
        debugging support with the CK binary:

            ./gdb /alliance/development/CK/binaries/CK

    6.  Initiate remote debugging in GDB, like this:

            target remote lpt2

        Replace lpt2 with the name of the host parallel port.
        The target machine should now say "debugger attached".

    7.  Have fun debugging !

------------------------

There is still a bug in this code too:  the machine reboots on receiving
an unexpected interrupt.  I'll have this fixed soon, too.  For the rest,
I still need to implement some things here but all the things you'll want
to use most often (step, breakpoint, continue, backtrace, memory dump and
set, etc.) work.

Summary:  there have been a lot of advances in the last week, but the tree
currently in CVS contains fatal bugs.  These will be fixed in the next tree.

What's on my schedule for the immediate future:
- Fix the bugs in the shared memory code and in the remote GDB code
- Generally clean up the tree:
  - Clean up the split structures and code comments
  - Clean up the build environemnt, so you can choose using an environment
    variable whether you want remote debugging or not
  - Clean up the debugging environment so that you can seamlessly switch
    between the new (GDB) debugging code and my old hardware debugging kludge,
    for the two-computer-less people among us :)

When that's done, I'll post another status update with my next set of TODO
stuff :)

Cyas,
Ramon



-
Alliance:	http://www.allos.org/
Archive:	http://humbolt.nl.linux.org/lists/