Re: Call Stack (Reflection)

Re: Call Stack (Reflection)

[peeter joot]

Hi Frank,

The glibc-2.1 source code has stack traceback functions built-in.  You
could use that code -- it is actually quite simple.

These will give you the addresses, and you can use one of the dl
functions (dladdr?) to give you the names.

For demangling you can use the bfd library, or (in a pinch) a pipe to
c++filt.

Peeter
--
Peeter Joot                                          peeterj@ca.ibm.com

Re: Call Stack (Reflection)

[Frank Pilhofer]

  Hi,

 a while ago, I asked about how to acquire a call stack in a running
program for building a memory leakage checker. Thanks for your help.
I now have the package ready and running on Linux/x86 and almost
running on SunOS/Sparc. If anybody is interested, see
 http://www.informatik.uni-frankfurt.de/~fp/Tools/MemTrace/

	Frank


-- 
 + Frank Pilhofer                        fp@informatik.uni-frankfurt.de  +
 |                                      http://www.uni-frankfurt.de/~fp/ |
 +---- Life would be a very great deal less weird without you.  - DA ----+

Re: Call Stack (Reflection)

[Frank Pilhofer]

On Mon, Jan 18, 1999 at 09:37:03AM -0500, Zack Weinberg wrote:
>
> dladdr() won't give you anything useful except for exported dynamic
> symbols in shared objects (i.e. libraries and modules loaded with
> dlopen()).  You want to print out the raw addresses and use addr2line
> to clean them up.  Take a look at debug/catchsegv.sh in the libc
> code.  I wouldn't bother with backtracesyms() at all.
>

 Yes, that works, thanks. I've borrowed some code from addr2line.c and
can now properly decode my backtrace. However, that currently only seems
to work on Linux.
 I've used the "generic" backtrace() function from glibc/sysdeps/generic/
backtrace.c, which uses __builtin_frame_address(0) to access the toplevel
frame. On SunOS, this produces a single stack frame pointing into an egcs
function (gcc/frame.c:0). On HPpa, I get nothing at all. All this is using
egcs 1.1a.
 Do you know of other (generic or system-specific) possibilities to
access a backtrace?

	Frank


-- 
 + Frank Pilhofer                        fp@informatik.uni-frankfurt.de  +
 |                                      http://www.uni-frankfurt.de/~fp/ |
 +---- Life would be a very great deal less weird without you.  - DA ----+

Re: Call Stack (Reflection)

[Andreas Jaeger]

>>>>> Frank Pilhofer writes:

 >   Hi,

 >  I'd like to have some information/examples of accessing the debugging/
 > profiling data produced by gcc within the program itself. I'm interested
 > in writing code that prints a back trace of cleartext function names,
 > like gdb does. The general idea is, in C++, to overload the new and
 > delete operators, and to associate each chunk of memory with a back
 > trace, to check for memory leakage.
 >  After browsing libgcc2.c, it seems that there are already hooks that
 > generate the necessary information. But from reading the source, I
 > don't know how to activate, use or evaluate it. In a simple test program,
 > compiled and linked with -a -pg -g (linux-glibc1), __bb.blocks is always
 > NULL.
 >  Is there some documentation, or is there some example source that
 > could help me? Or is there a package that already does what I intend
 > to do? -- I doubt I'm the first one to think of this possibility.

Have a look at glibc 2.1 (a test release called glibc-2.0.110 is
available from ftp://alpha.gnu.org/gnu ).  It provides output of the
backtrace for different architectures.  The implementation can be
found in the debug and sysdeps subdirs (backtrace* functions).

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

Call Stack (Reflection)

[Frank Pilhofer]

  Hi,

 I'd like to have some information/examples of accessing the debugging/
profiling data produced by gcc within the program itself. I'm interested
in writing code that prints a back trace of cleartext function names,
like gdb does. The general idea is, in C++, to overload the new and
delete operators, and to associate each chunk of memory with a back
trace, to check for memory leakage.
 After browsing libgcc2.c, it seems that there are already hooks that
generate the necessary information. But from reading the source, I
don't know how to activate, use or evaluate it. In a simple test program,
compiled and linked with -a -pg -g (linux-glibc1), __bb.blocks is always
NULL.
 Is there some documentation, or is there some example source that
could help me? Or is there a package that already does what I intend
to do? -- I doubt I'm the first one to think of this possibility.

	Frank


-- 
 + Frank Pilhofer                        fp@informatik.uni-frankfurt.de  +
 |                                      http://www.uni-frankfurt.de/~fp/ |
 +---- Life would be a very great deal less weird without you.  - DA ----+

Re: Call Stack (Reflection)

[Zack Weinberg]

On Mon, 18 Jan 1999 15:30:08 +0100, Frank Pilhofer wrote:
>On Sun, Jan 17, 1999 at 08:12:22PM +0100, Andreas Jaeger wrote:
>>
>> Have a look at glibc 2.1 (a test release called glibc-2.0.110 is
>> available from ftp://alpha.gnu.org/gnu ).  It provides output of the
>> backtrace for different architectures.  The implementation can be
>> found in the debug and sysdeps subdirs (backtrace* functions).
>>
>
> Thanks for the pointer. I have managed to extract the source and to
>compile the backtrace code by using dladdr() instead of _dl_addr().
>However, all I see in the backtrace is addresses which do not get
>resolved into symbolic names.
> Further testing shows that dladdr() succeeds, but returns an empty
>file name and the "nearest" symbol name `_start'. Do I have to use
>special compile-time or link-time options? At the moment, I use -g
>-fno-omit-frame-pointer.

dladdr() won't give you anything useful except for exported dynamic
symbols in shared objects (i.e. libraries and modules loaded with
dlopen()).  You want to print out the raw addresses and use addr2line
to clean them up.  Take a look at debug/catchsegv.sh in the libc
code.  I wouldn't bother with backtracesyms() at all.

zw

Re: Call Stack (Reflection)

[Frank Pilhofer]

On Mon, Jan 18, 1999 at 12:15:07PM -0500, Zack Weinberg wrote:
>
> To get this stuff to work in general, you need to get the ABI
> reference for the machine you're on and figure out where it stores
> return addresses.  Then you need to write code - likely ugly assembly
> language - to extract them.
>

 That's one reason why I'd like to tap into egcs's profiling code,
which looks as it if produces a call stack in nicely usable form.

 Anyway, the code I've borrowed from glibc, binutils and gdb works
quite well so far. I now log calls to malloc() and free() and can
print cleartext backtraces for chunks of allocated but unreleased
memory. Anybody interested in (checking, proofreading, commenting
on) the package?

	Frank

-- 
 + Frank Pilhofer                        fp@informatik.uni-frankfurt.de  +
 |                                      http://www.uni-frankfurt.de/~fp/ |
 +---- Life would be a very great deal less weird without you.  - DA ----+

Re: Call Stack (Reflection)

[Frank Pilhofer]

On Sun, Jan 17, 1999 at 08:12:22PM +0100, Andreas Jaeger wrote:
>
> Have a look at glibc 2.1 (a test release called glibc-2.0.110 is
> available from ftp://alpha.gnu.org/gnu ).  It provides output of the
> backtrace for different architectures.  The implementation can be
> found in the debug and sysdeps subdirs (backtrace* functions).
>

 Thanks for the pointer. I have managed to extract the source and to
compile the backtrace code by using dladdr() instead of _dl_addr().
However, all I see in the backtrace is addresses which do not get
resolved into symbolic names.
 Further testing shows that dladdr() succeeds, but returns an empty
file name and the "nearest" symbol name `_start'. Do I have to use
special compile-time or link-time options? At the moment, I use -g
-fno-omit-frame-pointer.

	Frank


-- 
 + Frank Pilhofer                        fp@informatik.uni-frankfurt.de  +
 |                                      http://www.uni-frankfurt.de/~fp/ |
 +---- Life would be a very great deal less weird without you.  - DA ----+

Re: Call Stack (Reflection)

[Frank Pilhofer]

  Hi,

 a while ago, I asked about how to acquire a call stack in a running
program for building a memory leakage checker. Thanks for your help.
I now have the package ready and running on Linux/x86 and almost
running on SunOS/Sparc. If anybody is interested, see
 http://www.informatik.uni-frankfurt.de/~fp/Tools/MemTrace/

	Frank


-- 
 + Frank Pilhofer                        fp@informatik.uni-frankfurt.de  +
 |                                      http://www.uni-frankfurt.de/~fp/ |
 +---- Life would be a very great deal less weird without you.  - DA ----+