[lug] Stack trace question

D. Stimits stimits at idcomm.com
Wed Aug 16 18:50:29 MDT 2000


That's a whole different story. But, it isn't entirely impossible.
Probably the biggest problem is the lack of -g, which is what provides
symbols to put caller/callee into english, rather than more machine-like
references. One can disassemble almost anything, but it doesn't
necessarily get you anywhere in terms of useful information. So one big
question is whether tracing is going to be a one-way or two-way thing.
Do unknown functions have to get info from yours, or does yours have to
get info from others?

I'm not sure of any *easy* way to do this, but you will probably be very
interested in the ptrace function (man ptrace, #include <sys/ptrace>).
ptrace() is the basis behind most debuggers. It enables you to embed
into your application any ability a debugger has. You can't magically
suck out the function name from a function that has had symbols
stripped, but you can do a few tricks in some cases. The command "nm" is
able to read function signatures from most libs and binary files, and
cross-reference that to binary offsets. So you could combine the two for
some potent abilities, but nm is not itself a C function. Probably you
would want get the source to nm and find out how it reads things, along
with the glib symbol format that nm displays. There are, for example,
abbreviations for various function arguments. If you are using C++ and
name mangling is present, without any control over using extern "C"
around the function, you're in a world of hurt. Even here, it isn't
hopeless though. There is another program, "c++filt", a command line
program, useful for demangling. Symbol mangling in C++ is rather
specific to compilers and platforms, and is also expected to be modified
in the near future on linux, so this would be non-portable, and require
changes sometime not too far down the road.

Perhaps what would be useful is to know more about what parts of the
program will need this information...if your code needs info about
foreign code, or if foreign code needs info about your code, so on,
could change things somewhat (especially what languages are
involved...strictly C versus C++, and libs versus .o object files, so
on). I probably can't add more on this, but with a more explicit
description, someone here might.

D. Stimits, stimits at idcomm.com

Dan Wilson wrote:
> 
> I want to implement that myself in myfunction().  I cannot assume all
> the applications which call my library are compiled using -g.
> most likely they don't have even symbols.  I just need to know the call
> stack
> that calls myfunction() and see which module it is coming from.
> 
> Thanks
> Dan
> 
> >From: "D. Stimits" <stimits at idcomm.com>
> >Reply-To: lug at lug.boulder.co.us
> >To: lug at lug.boulder.co.us
> >Subject: Re: [lug] Stack trace question
> >Date: Wed, 16 Aug 2000 17:46:46 -0600
> >
> >Dan Wilson wrote:
> > >
> > > Hi All,
> > >
> > > In my program I want to trace the stack and see every function within
> > > the stack and what module it is coming from.  If main() calls foo() from
> > > foo.so and foo called bar() from bar.so and bar() called myfunction()
> >from
> > > mylibrary.so,  In myfunction() I want to see bar() coming from bar.so
> > > and foo() coming from foo.so and so on.  No clue how to do this any
> > > help is greatly appreciated.
> > >
> > > Thank you
> > > Dan
> > >
> > > ________________________________________________________________________
> > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
> > >
> > > _______________________________________________
> > > Web Page:  http://lug.boulder.co.us
> > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >
> >gdb is the beast you need. Compile with -g, and don't use -O2 (or
> >-OsomethingOptimized).
> >
> >What you are looking for is "bt". Inside the debugger, type "help bt".
> >It should give you info sufficient to see not only the calls, but the
> >arguments passed. If you are using threads, it gets more complicated,
> >and generally you'd need a patch for threads under stock gdb.
> >
> >_______________________________________________
> >Web Page:  http://lug.boulder.co.us
> >Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> 
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug




More information about the LUG mailing list