It wouldn't surprise me if kobj_getsymname() needed a lock that was being held by the thread doing modload. (Modload changes the kernel symbol table by loading in a new binary, after all.)

   - Garrett

Peter Teoh wrote:
Thank you James for the tip.

Following your advice, and following the similar getpcstack()'s usage
as example at:

uts/common/os/policy.c

I coded thus:

    23  int _init(void)
    24  {
    25        int i, depth, status;
    26        pc_t mystack[1024];
    27        char *sym;
    28        ulong_t off;
    29
    30        status = mod_install(&modlinkage);
    31        cmn_err(CE_NOTE,"me filed\n");
    32        depth = getpcstack(mystack, 10);
    33          for (i = 0; i < depth; i++) {
    34                  sym = kobj_getsymname((uintptr_t)mystack[i], &off);
    35                  cmn_err(CE_NOTE, "sym=%s %x %d\n", sym, (uintptr_t) myst
ack[i], off);
    36          }
    37        return status;
    38  }

Technically is there any problem with this piece of code?

modloading it will result in hanging the system.

On Sun, Aug 23, 2009 at 12:18 PM, James Carlson<carls...@workingcode.com> wrote:
Peter Teoh wrote:
Is there any equivalent function like dump_stack() in Linux kernel,
whereby I can easily just dump the stacktrace at any point in the
kernel source?
getpcstack() will do what you're asking.  (There's also traceback(), but
that's probably not quite what you want.)

getpcstack() stores the stack information in an array so that you can
display it later, or just keep it in memory and examine it later with mdb.

And perhaps another macro function to dump all the registers as well?
I don't know of one for that.  I also don't know why you'd ever want to
do that.  Why dump the registers?  Why not just add dtrace sdts for the
information you really want to display?

(The only use I can imagine right now would be producing an inscrutable
error message, like the blue screen on Windows or "oops" on Linux.  I'm
not sure why anyone would want that ...)

--
James Carlson         42.703N 71.076W         <carls...@workingcode.com>





_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to