[MUD-Dev] Re: TECH: Distributed Muds

[Chris Gray]

> From: Bruce <bruce at puremagic.com>

> On a related note, I haven't seen a nice way of determining the
> stack trace for a given thread.  I'd love to know how to do this.  I
> can walk a stack upwards given a jmp_buf, but what I really want to
> do here is be able to determine exactly what all of the threads in a
> running system are doing at any point in time.  This would obviously
> be platform-specific code, which is fine with me. :) Anyone done
> anything like this?

I've done it, but it wouldn't be of any help to you. I've done it in
my AmigaMUD system (both versions of the execution stuff), but since I
by definition have full knowledge of how the execution works, it
wasn't that hard. When you don't have that knowledge, its much
harder. For example, under HPUX, you actually have to examine the
instructions at the head of the function (which you determine based on
a global sorted table that the linker adds to your image), in order to
determine the size of the current stack frame, since there is no way
direct way to go from the current stack frame to the previous one. You
pretty much have to spend a few days staring at code produced by the
compilers in various cases, and make your backtrace code handle all of
the cases.

Too bad the Gnu folks don't make the backtrace facilities in gdb
available as a standalone library. Well, they don't that I know of.

If you are just concerned with X86, my recollection is that it isn't
all that bad. Especially if you are just worried about gcc-generated
code, and so don't have the varying models that the Windows compilers
can use.

--
Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg at ami-cg.GraySage.COM
               http://www.GraySage.COM/cg/
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev