My latest Seamonkey trunk build decided it wanted to die at
so I decided this was an opportunity to see what, if anything idebug could
show me. I quickly discovered that configure.in was not capable of
telling ilink to generate debug data, so I applied to following to resolve
Re: What's the state of gcc source level debugging?
Steven Levine wrote:
> My latest Seamonkey trunk build decided it wanted to die at
> XPCONECT.DLL 0001:0002f880
> so I decided this was an opportunity to see what, if anything idebug could
> show me.
> This produced is debug data, but apparently no source line debug data. Am
> I missing a configuration option, or is our gcc not yet capable of this?
You need --enable-debug and --disable-optimize in your .mozconfig. That
gives you all the debug data you need (and more) but I found IDebug to
be somewhat unstable, ICSDebug from VAC++ 3.08 was better.
>You need --enable-debug and --disable-optimize in your .mozconfig. That
>gives you all the debug data you need (and more)
I didn't want to build with full debug and was attempting to use
--enable-debug-info-modules to be selective. The patch is needed to make
this option work correctly, but I supplied the wrong flag. This patch
gets usable debug data and a per module basis. I'll create a bug for this
so it can get reviewed.
Of course, whatever the problem was is now gone and seamonkey again starts
up correctly. This is probably the result of a cvs update.
I still have a need for debug data because I seem to have a problem with
the Java plugin. About plugins shows the expected content, but I can not
open the Java console. I recall reading something to the effect that
Seamonkey have problems with the Java plugin, but I can't find a reference
>but I found IDebug to be
>somewhat unstable, ICSDebug from VAC++ 3.08 was better.
I've got my debug environment setup so I can choose whichever seems to
work better. I should checkout OpenWatcom 1.4. Michal and I discussed
HLL debug support and I'm not sure this got implemented.
>Did you have any time to work on ExceptQ? This would have been the
>perfect opportunity to try it out. :-)
I've been pretty well slammed with other tasks. I've got some work in
progress, but nothing that others can use. I need to straigthen out the
32-bit detect logic. The original code decides that the stack and code is
16-bit more often than it should. I'm also hoping to replace the CodeView
support with HLL support which will allow much more use display of the