Re: Problem with "file" command from CVS_HEAD

[Keith Seitz <keiths@redhat.com>]

On Wed, 2005-05-18 at 01:54 -1100, Steven Johnson wrote:
> Take 3.

That's okay. Just look at how long it has taken me to take a peek at
it!! Shame on me.

> gdb_loc is the same as before, it return the address of entry_point when 
> there are no registers as current $pc.  Seems fine, and the most 
> appropriate default.

This seems reasonable. I will run it through the testsuite just to make
sure. :-)

> The problem i listed as 1.c) about the pop up showing: (Internal error: 
> pc 0x0 in read in psymtab, but not in symtab.).  Was actually through a 
> side effect causing error 1.b) the 3 Drop downs present under the button 
> bar for file, function and mode failing to appear.  I get rid of the pop 
> up warning box, and the 3 drop downs re-appear, strange i know.  My 
> presumption is that the error box was preventing a sequence of code 
> executing.

Hmm. That's kinda goofy. That means that startup code is being short-
circuited when a warning message appears.

You know, at one time, we could actually pop the GUI up BEFORE we tried
to load the executable. I really wish I knew why this stopped working
several years ago. :-(

> Word of warning to everyone. GDB debug flags are incompatible with 
> insight.  If you need to use them, use --nw find your problem, fix it, 
> and disable the debug flags "before" worrying about insight.  Otherwise 
> you will get all sorts of strange results. And you might end up pulling 
> your hair out for days before identifying what i just did as the cause.

Ah, yeah, that can do that. The problem is that although insight
*largely* does not parse gdb output, things like the register and memory
windows do get the output of several gdb functions (most notably
val_print). Sometimes the warnings come with the values, and insight can
get confused. One of these days I'll track all these buggers down...

> So no patch required to fix 2.b-2.g of my second report, as they are all 
> caused by GDB debug message options being enabled.
> 
> Comments or Criticisms?

I only have one comment. I would prefer that we discuss the warning
portion of the patch separately: we can make those warnings ignorable.
Perhaps we can suppress warnings (to a dialog) during startup or
something. In any case, I don't think we want to ignore an internal
error, do we? Hmm. I guess there are actually different levels of
internal error? Some critical and some not?

What do you think?
Keith