[lug] insight as gdb frontend?

[Scott A. Herod]

Thanks for the note, Tom.

I was seeing the "make install" bug posted about Jan. 3 which
mentions missing hard-coded install paths in one of the subdirectories.
( I'd followed directions "./configure", "make", "make install". 
BTW, I also have problems with make installs that write in the
build tree location.  I don't give root write access to the place
where I do most builds. )

Anyway, it turned out that one of our occasional contractors,
a former Cygnus person, had built himself a version of Insight
and raved about it, so I'm giving it more of a look.  Still, 
I'm afraid that I sorely miss Casevision Workshop, although
even it didn't work particularly well with multi-threaded apps.

Scott

Tom Tromey wrote:
> 
> >>>>> "Scott" == Scott A Herod <herod at interact-tv.com> writes:
> 
> Scott>   Any thoughts about Insight <http://sources.redhat.com/insight/>
> Scott> as a frontend to gdb?  I'm a bit nervous about going to the effort
> Scott> to fix the installation since I'm hitting a bug that's been open
> Scott> for at least 4 months.  ( I'm glad I wasn't doing an install into
> Scott> /usr rather than /usr/local.  I'd be really upset if gdb had been
> Scott> broken. )  Maybe the CVS code has been corrected.
> 
> I've hacked on and used Insight.
> 
> It is ok.  Some things it does very nicely.  Overall it seems fast
> enough.  When debugging unfamiliar code I tend to use it instead of
> the command-line gdb.  (When debugging familiar code I tend to use the
> command line gdb or gdb in Emacs.)
> 
> Sometimes Insight crashes.  But then, I've noticed that recently gdb
> crashes a lot too, so it is hard to attribute the crashes to Insight
> per se.  In particular there are problems if you rebuild the inferior
> and then re-run it, especially when you have breakpoints in shared
> libraries.
> 
> I might see more problems since I tend to use the cvs gdb.
> 
> BTW, a word of advice: don't ever configure programs with
> --prefix=/usr.  That way lies madness.  My preferred way to build is
> to make a new install directory for every program.  Then I can simply
> `rm -rf' the hierarchy if it isn't working out.  Of course, I also
> tend to have 3 or 4 gcc installations and 2 gdb installations at any
> given time; I doubt my needs are typical.
> 
> Tom