From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29679 invoked by alias); 27 May 2005 02:27:19 -0000 Mailing-List: contact insight-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 29670 invoked by uid 22791); 27 May 2005 02:27:16 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 27 May 2005 02:27:16 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4R2BABn018915 for ; Thu, 26 May 2005 22:11:10 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4R2BAO30544; Thu, 26 May 2005 22:11:10 -0400 Received: from localhost.localdomain (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id j4R2B822010148; Thu, 26 May 2005 22:11:09 -0400 Subject: Re: Problem with "file" command from CVS_HEAD From: Keith Seitz To: Steven Johnson Cc: "insight@sources.redhat.com" In-Reply-To: <428B3AFA.70401@sakuraindustries.com> References: <42896CAD.60504@sakuraindustries.com> <4289CFD6.6040306@sakuraindustries.com> <1116286740.4493.9.camel@lindt.uglyboxes.com> <428A79EE.4080307@sakuraindustries.com> <428B3AFA.70401@sakuraindustries.com> Content-Type: text/plain Date: Fri, 27 May 2005 02:27:00 -0000 Message-Id: <1117159868.4456.127.camel@lindt.uglyboxes.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-q2/txt/msg00099.txt.bz2 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