Re: memprof trouble on debian

[Owen Taylor <otaylor redhat com>]

Michael Meeks <michael ximian com> writes:

> Hi Owen,
> 
> On Tue, 2002-10-08 at 12:50, Owen Taylor wrote:
> > But what's the point? It might make it compile on Solaris, but is it going
> > to _work_ on Solaris? Linux-specific stuff in MemProf is very extensive...
> 
> 	No - it's not going to work on Solaris - but it's almost certainly more
> likely not to work if it doesn't compile.

Straightforward cleanups are fine, but I don't want to take code that adds
complexity if there isn't a useful end-goal in sight, even if the complexity
is small.
 
> > I guess the straightforward profiling stuff might have half a chance if you
> > figured out how to do backtraces on SPARC, but the memory leak stuff would
> > take a lot more work.
> 
> 	I've no idea how to do back-traces on SPARC - I imagine a very similar
> method would work - when I had the machine running, we had libbfd
> kicking around - which I assumed helped with that.

bfd doesn't help with this at all... what we need to do is take fast
backtraces in process; right now there is a simple hardcoded stack
unwinder for i386.

We are most likely going to have to go to a more complicated stack
trace system for Linux in the future -- using the dwarf unwind 
information emitted by newer versions of gcc. 

(Will allow dealing with -fomit-frame-pointer and
-fomit-leaf-frame-pointer, and also deal better with various 
optimizations)

I'm not sure that it will really help portability though.
 
> > (The locking stuff should be easier to adopt for Solaris now -- all you
> > need to do is provide an implementation of mi_atomic_increment() and
> > mi_atomic_decrement())
> 
> 	Why not use GThread ? you're worried that it might do dynamic
> allocation in future ? presumably so might pthread_* ?

The code doesn't use pthread_ anymore either. The reasons for avoiding
using a threading library primitivse:

 - When intercepting thread creation (on Linux) we need to do our locking
   between the clone syscall and the point where the thread actually
   starts.
 
   (There was an elaborate workaround to try to avoid using pthread_*
   then that your patch, if I recall correctly, removed)

 - When time profiling, the code can be called at *any* time, including
   when the threading system is in a bad state

 - And yes, threading system might do memory allocation.

Regards,
                                        Owen