[Mono-list] JIT patch for stabs debugging

[Paolo Molaro]

On 03/10/02 Martin Baulig wrote:
> > No, this is wrong: if you restart mono, all the infos in the stab file
> > are wrong. It may have happened that in two runs the same method was
> > assigned the same address by malloc, but you can't rely on it:-)
> > I don't know if a recent gdb allows to unload a debug object, if it
> > still doesn't, you need to quit and restart gdb as well (and recompile
> > the stabs each time you start mono).
> 
> Sure, that's right. The problem is that SIGABRT usually is normally a
> deadly signal for a process - so you can't run "mono --stabs --debug"
> in a shell. On the other hand, running it in gdb to create the stabs
> files is very inconvenient since you must hit enter each time it
> reaches a breakpoint.

Can't you just use mono --stabs (without --debug) if you simply want to
have a look at the stab information? Note, though, that as soon as the
process that generated the stabs is finished, the data becomes useless
for debugging the app (but it can be useful to debug the stabs support
itself for types etc.).

> In most situations, running mono several times with the same stabs
> file should work fine as long as the program flow stays the same - for
> instance, you have a test case which takes no user input and always
> produces the same output. There, being able to restart the program
> with different --debug arguments can be very useful.

This is the wrong way to do it: it's like saving the address returned by
malloc() in a file, quitting the program, restarting, calling malloc()
again throwing away the result and using the value saved before in the
file. This doesn't work, you should not rely on such ugly kludges.

Please don't commit to cvs controversial changes until you can convince
the list that reusing the result of malloc() in a different process is
safe (you'll have a hard time at that...).

I just read the gdb manual: you can use the symbol-file command without
arguments to discard previous symbol information, so there is no reason
to add unsafe kludges to the JIT code.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better