Re: interesting ORBit behavior
> Heh, well I am interested, i'm just not sure how to help figure it out.
> I'm really quite a newbie to actually developing for HURD.
There's only one cure for that!
> My translator which is trivial (creates a virtual file full of 'y's), but
> is linked with ORBit, dies with the same error with all the CORBA calls
> commented out as without:
>
> nick@fugue:~/local/testtrans$ settrans -ac foo random-dot-org
> nick@fugue:~/local/testtrans$ less foo
> foo: (system server) error with unknown subsystem
Stick to something simpler like "cat" to test your translator's i/o.
Also, try testing the node operations first, i.e. "ls -l foo".
Have you had success with a trivial translator like the ones in
hurd/trans/{hello,hello-mt}.c? I would suggest starting from the simplest
thing, making small additions, and testing again in between to find what
additions being to complicate things.
> I made an rpctrace of a cat foo which is at
>
> http://www.grawk.net/~nick/proj/hurd/testtrans/rpctrace-of-random-dot-org-failure
That output looks like it's from an older version of rpctrace. The output
from the current rpctrace is a bit better organized (though still quite
cryptic to most people). rpctrace lives in one file that is easily
compiled outside of the hurd source tree; you can just grab
utils/rpctrace.c from the sources and compile it:
cc -D_GNU_SOURCE -g -o rpctrace rpctrace.c -lports -lihash -lthreads
> I'm not sure how to interpert it, I'm also not sure how to debug
> this. How do I see where its getting to with gdb or whatever?
Several people have expressed interest in improving rpctrace, but noone has
actually done anything about it. You have already found your own
motivation for wanting better output from rpctrace, so perhaps you would
like to work on that? The first thing it needs to start being
comprehensible is to output RPC names instead of raw msgid numbers.
Understanding the rpctrace output is one of the best ways to understand the
fundamental architecture of the Hurd.
I certainly encourage you to improve rpctrace and learn about your
translator's problems that way. That work will help a lot of other people
in the future as well. But to just debug your translator per se, you can
simply attach gdb to it and go to town.
Reply to: