Re: mprof and new systems..

From: Robert Watson <rwatson_at_FreeBSD.org>
Date: Sat, 14 Jun 2008 15:43:30 +0100 (BST)
On Sat, 14 Jun 2008, Julian Elischer wrote:

> mprof is a memory allocation profiler.
>
> as part of what it does it reads the stack for a call graph.
>
> it finds the current frame pointer from the address of a variable on the 
> stack and then from that traces back to previous return addresses.
>
> however there is a catch, at least on i386..
>
> with -O2 the variable is 4 bytes below the fp and without it it is 12 bytes 
> below. so it has to know how it was compiled to get it right.
>
> in addition, with -O2 it seems that the address of the variable may actually 
> be wring if the optimiser never bothers to have the variable actually saved.

I'm not sure if you've seen it or not, but stack(9) provides an automated 
stack capture facility for the kernel.  It may not be ideal for your use, but 
it isn't a bad starting point for things along this line, and it works on 
(almost) all architectures in a portable way.  It might need some extending 
for your purposes.

Robert N M Watson
Computer Laboratory
University of Cambridge

>
>
> one possibility would be to use #asm to just give the value of %ebp
>
> currently it does:
>
>
>
> findretaddr()
> {
>  int first_var;
>  u_int *fp
>  u_int *retptr
>
>
>  fp = ((char *)(&first_var)) + 4;  /* needs to be 12 if no -O2 */
>  retptr = ((char *)fp) + 4;
>  prev_fp = *fp;
>
>  [...]
>
>
> }
>
> Anyone with ideas as to how to make the port act reliably?
>
> mprof is really cool but thos probelm makes it hard to use.
> you have ot make sure you compile the library itself without -O
> and change the code..
>
> why it needs to be 12 is unknown  the compiler seems to want
> to push extra regs before savinghte frame pointer.
>
>
>
>
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
Received on Sat Jun 14 2008 - 12:43:31 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:31 UTC