Problem with "file" command from CVS_HEAD

Problem with "file" command from CVS_HEAD

[Steven Johnson]

I have a problem with insight from CVS_HEAD and the "load" command.

If i start Insight with --nw, and use "file" it does what i expect, and 
loads the file i wish to debug. (No Problem)

If i start insight with the gui enabled, and use "file".  I get a 
segfault, after "insight" has recursively tried to call 
"target_fetch_registers(pc)"  I say recursively, because i started 
"insight" under GDB (native) and the back trace was enourmous (actually 
segfaulted GDB before it could finish),  and had an obvious recursive 
call structure through the code which reads the pc register.

I have various debug options enabled, and immediately after the "file" 
command, insight reports in the debug log:

architecture_changed_event
{ flush_cached_frames () }
target_terminal_ours ()
No symbol table is loaded.  Use the "file" command.
target_terminal_ours ()
No symbol table is loaded.  Use the "file" command.
target_terminal_ours ()
No symbol table is loaded.  Use the "file" command.
target_terminal_ours ()
No symbol table is loaded.  Use the "file" command.
target_terminal_ours ()
No symbol table is loaded.  Use the "file" command.
Operating system is "".
target_terminal_ours ()
No symbol table is loaded.  Use the "file" command.
target_terminal_ours ()
No symbol table is loaded.  Use the "file" command.
target_terminal_ours ()
No symbol table is loaded.  Use the "file" command.
target_terminal_ours ()
No symbol table is loaded.  Use the "file" command.
target_terminal_ours ()
No symbol table is loaded.  Use the "file" command.
observer_notify_executable_changed() called
{ flush_cached_frames () }
target_xfer_memory (0x32478, xxx, 4, read, xxx) = 4, bytes = 94 21 ff f8
target_xfer_memory (0x3247c, xxx, 4, read, xxx) = 4, bytes = 7c 08 02 a6
target_xfer_memory (0x32480, xxx, 4, read, xxx) = 4, bytes = 90 01 00 0c
target_xfer_memory (0x32484, xxx, 4, read, xxx) = 4, bytes = 4b fd db 5d
target_xfer_memory (0x32488, xxx, 4, read, xxx) = 4, bytes = 3d 20 00 55
target_fetch_registers (pc)target_fetch_registers 
(pc)target_fetch_registers (pc)target_fetch_registers 
(pc)target_fetch_registers (pc)target_fetch_registers 
(pc)target_fetch_registers (pc)target_fetch_registers 
(pc)target_fetch_registers (pc)target_fetch_registers 
(pc)target_fetch_registers (pc)..........many many times.
**segfault**

I believe the segfault occurs, because the program stack is exhausted by 
the recursive call to target_fetch_registers (pc)

The problem is, i havent connected to the target yet, so how can it read 
memory, or fetch registers at all.

This seems to be restricted to insight, so my first thought is, insight 
isnt checking something that GDB does, and so is executing things GDB 
normally doesnt on a "file" load.  I dont mind trying to correct this, 
but I do not have any idea where to start looking.  Some pointers of 
where I should look, or how "file" differs when insight is running, as 
opposed to GDB would be appreciated.

Thanks in advance,
Steven Johnson

Re: Problem with "file" command from CVS_HEAD

[Accounts]

[-- Attachment #1: Type: text/plain, Size: 4526 bytes --]

I have found the problem.  What happens is this:

after a "file" command, gdb_loc is called by tcl, with no arguments.  
This makes gdb_loc look up the current PC.  BUT, after a "file" command, 
(with a remote target) we do not have a "pc", because we havent had a 
chance to do a "target remote ...", which you do AFTER you specify the 
file to debug.  So, i have modified gdb_loc, so if there is an attempt 
to look up the "pc" and there are no target registers yet, it returns an 
appropriate error.  In that way the TCL Code can do what it needs to in 
this situation, and we dont generate a segfault.

It is possible that there are calls the gdb_loc for $pc, which do not 
properly handle this error,  I believe this is a seperate issue, and 
they will become plain with time.  I have not experienced any problems 
(with my brief testing) to indicate this is actually the case.

I Believe this is the correct thing to do.

Attached is a patch against CVS_HEAD, doing just this.

I have tested on an PowerPC:MPC8XX embedded system and it fixes the problem.

I Believe this problem is peculiar to remote targets and local targets 
would not be effected.

Comments?  Is the code formating correct? Is the comment appropriate?

Also, while this seems to fix the segfault i was experiencing with 
"file" I now have other problems, although they appear to be unrelated.

Steven Johnson

Steven Johnson wrote:

> I have a problem with insight from CVS_HEAD and the "load" command.
>
> If i start Insight with --nw, and use "file" it does what i expect, 
> and loads the file i wish to debug. (No Problem)
>
> If i start insight with the gui enabled, and use "file".  I get a 
> segfault, after "insight" has recursively tried to call 
> "target_fetch_registers(pc)"  I say recursively, because i started 
> "insight" under GDB (native) and the back trace was enourmous 
> (actually segfaulted GDB before it could finish),  and had an obvious 
> recursive call structure through the code which reads the pc register.
>
> I have various debug options enabled, and immediately after the "file" 
> command, insight reports in the debug log:
>
> architecture_changed_event
> { flush_cached_frames () }
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> Operating system is "".
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> observer_notify_executable_changed() called
> { flush_cached_frames () }
> target_xfer_memory (0x32478, xxx, 4, read, xxx) = 4, bytes = 94 21 ff f8
> target_xfer_memory (0x3247c, xxx, 4, read, xxx) = 4, bytes = 7c 08 02 a6
> target_xfer_memory (0x32480, xxx, 4, read, xxx) = 4, bytes = 90 01 00 0c
> target_xfer_memory (0x32484, xxx, 4, read, xxx) = 4, bytes = 4b fd db 5d
> target_xfer_memory (0x32488, xxx, 4, read, xxx) = 4, bytes = 3d 20 00 55
> target_fetch_registers (pc)target_fetch_registers 
> (pc)target_fetch_registers (pc)target_fetch_registers 
> (pc)target_fetch_registers (pc)target_fetch_registers 
> (pc)target_fetch_registers (pc)target_fetch_registers 
> (pc)target_fetch_registers (pc)target_fetch_registers 
> (pc)target_fetch_registers (pc)..........many many times.
> **segfault**
>
> I believe the segfault occurs, because the program stack is exhausted 
> by the recursive call to target_fetch_registers (pc)
>
> The problem is, i havent connected to the target yet, so how can it 
> read memory, or fetch registers at all.
>
> This seems to be restricted to insight, so my first thought is, 
> insight isnt checking something that GDB does, and so is executing 
> things GDB normally doesnt on a "file" load.  I dont mind trying to 
> correct this, but I do not have any idea where to start looking.  Some 
> pointers of where I should look, or how "file" differs when insight is 
> running, as opposed to GDB would be appreciated.
>
> Thanks in advance,
> Steven Johnson
>
>


[-- Attachment #2: insight-6.3.50-gdb_loc-no-registers.patch --]
[-- Type: text/x-patch, Size: 738 bytes --]

diff -Naur gdb-6.3/gdb/gdbtk/generic/gdbtk-cmds.c gdb-6.3-modified/gdb/gdbtk/generic/gdbtk-cmds.c
--- gdb-6.3/gdb/gdbtk/generic/gdbtk-cmds.c	2005-05-15 21:49:09.000000000 -1100
+++ gdb-6.3-modified/gdb/gdbtk/generic/gdbtk-cmds.c	2005-05-16 23:20:03.338797451 -1100
@@ -2114,6 +2114,15 @@
 
   if (objc == 1)
     {
+      /* This function can be called, before the target is properly
+         set-up, the following prevents an error, by trying to
+	 read_pc when there is no pc to read. */
+      if (!target_has_registers)
+        {
+	  gdbtk_set_result (interp, "Target has no PC", -1);
+	  return TCL_ERROR;
+	}  
+    
       if (deprecated_selected_frame
 	  && (get_frame_pc (deprecated_selected_frame) != read_pc ()))
         {

Re: Problem with "file" command from CVS_HEAD

[Steven Johnson]

[-- Attachment #1: Type: text/plain, Size: 4514 bytes --]

I have found the problem.  What happens is this:

after a "file" command, gdb_loc is called by tcl, with no arguments.
This makes gdb_loc look up the current PC.  BUT, after a "file" command,
(with a remote target) we do not have a "pc", because we havent had a
chance to do a "target remote ...", which you do AFTER you specify the
file to debug.  So, i have modified gdb_loc, so if there is an attempt
to look up the "pc" and there are no target registers yet, it returns an
appropriate error.  In that way the TCL Code can do what it needs to in
this situation, and we dont generate a segfault.

It is possible that there are calls the gdb_loc for $pc, which do not
properly handle this error,  I believe this is a seperate issue, and
they will become plain with time.  I have not experienced any problems
(with my brief testing) to indicate this is actually the case.

I Believe this is the correct thing to do.

Attached is a patch against CVS_HEAD, doing just this.

I have tested on an PowerPC:MPC8XX embedded system and it fixes the problem.

I Believe this problem is peculiar to remote targets and local targets
would not be effected.

Comments?  Is the code formating correct? Is the comment appropriate?

Also, while this seems to fix the segfault i was experiencing with
"file" I now have other problems, although they appear to be unrelated.

Steven Johnson

Steven Johnson wrote:

> I have a problem with insight from CVS_HEAD and the "load" command.
>
> If i start Insight with --nw, and use "file" it does what i expect, 
> and loads the file i wish to debug. (No Problem)
>
> If i start insight with the gui enabled, and use "file".  I get a 
> segfault, after "insight" has recursively tried to call 
> "target_fetch_registers(pc)"  I say recursively, because i started 
> "insight" under GDB (native) and the back trace was enourmous 
> (actually segfaulted GDB before it could finish),  and had an obvious 
> recursive call structure through the code which reads the pc register.
>
> I have various debug options enabled, and immediately after the "file" 
> command, insight reports in the debug log:
>
> architecture_changed_event
> { flush_cached_frames () }
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> Operating system is "".
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> target_terminal_ours ()
> No symbol table is loaded.  Use the "file" command.
> observer_notify_executable_changed() called
> { flush_cached_frames () }
> target_xfer_memory (0x32478, xxx, 4, read, xxx) = 4, bytes = 94 21 ff f8
> target_xfer_memory (0x3247c, xxx, 4, read, xxx) = 4, bytes = 7c 08 02 a6
> target_xfer_memory (0x32480, xxx, 4, read, xxx) = 4, bytes = 90 01 00 0c
> target_xfer_memory (0x32484, xxx, 4, read, xxx) = 4, bytes = 4b fd db 5d
> target_xfer_memory (0x32488, xxx, 4, read, xxx) = 4, bytes = 3d 20 00 55
> target_fetch_registers (pc)target_fetch_registers 
> (pc)target_fetch_registers (pc)target_fetch_registers 
> (pc)target_fetch_registers (pc)target_fetch_registers 
> (pc)target_fetch_registers (pc)target_fetch_registers 
> (pc)target_fetch_registers (pc)target_fetch_registers 
> (pc)target_fetch_registers (pc)..........many many times.
> **segfault**
>
> I believe the segfault occurs, because the program stack is exhausted 
> by the recursive call to target_fetch_registers (pc)
>
> The problem is, i havent connected to the target yet, so how can it 
> read memory, or fetch registers at all.
>
> This seems to be restricted to insight, so my first thought is, 
> insight isnt checking something that GDB does, and so is executing 
> things GDB normally doesnt on a "file" load.  I dont mind trying to 
> correct this, but I do not have any idea where to start looking.  Some 
> pointers of where I should look, or how "file" differs when insight is 
> running, as opposed to GDB would be appreciated.
>
> Thanks in advance,
> Steven Johnson
>
>



[-- Attachment #2: insight-6.3.50-gdb_loc-no-registers.patch --]
[-- Type: text/x-patch, Size: 739 bytes --]

diff -Naur gdb-6.3/gdb/gdbtk/generic/gdbtk-cmds.c gdb-6.3-modified/gdb/gdbtk/generic/gdbtk-cmds.c
--- gdb-6.3/gdb/gdbtk/generic/gdbtk-cmds.c	2005-05-15 21:49:09.000000000 -1100
+++ gdb-6.3-modified/gdb/gdbtk/generic/gdbtk-cmds.c	2005-05-16 23:20:03.338797451 -1100
@@ -2114,6 +2114,15 @@
 
   if (objc == 1)
     {
+      /* This function can be called, before the target is properly
+         set-up, the following prevents an error, by trying to
+	 read_pc when there is no pc to read. */
+      if (!target_has_registers)
+        {
+	  gdbtk_set_result (interp, "Target has no PC", -1);
+	  return TCL_ERROR;
+	}  
+    
       if (deprecated_selected_frame
 	  && (get_frame_pc (deprecated_selected_frame) != read_pc ()))
         {

Re: Problem with "file" command from CVS_HEAD

[Keith Seitz]

On Tue, 2005-05-17 at 00:04 -1100, Accounts wrote:

> It is possible that there are calls the gdb_loc for $pc, which do not 
> properly handle this error,  I believe this is a seperate issue, and 
> they will become plain with time.  I have not experienced any problems 
> (with my brief testing) to indicate this is actually the case.
> 
> I Believe this is the correct thing to do.

Hmm. I'm not so sure... So what happens if you're not running and you
type something like "tk gdb_loc main". Does it return something useful?

The problem is, of course, that there is no specific way to pass an
error like this to the UI (the error is really an ignorable one in this
case). We don't want invocations of gdb_loc to fail because we don't
have a running target. I guess we could always pass some sort of fixed
constant string (like "NOT_RUNNING" or something) instead of the PC
value to indicate no registers or not running...

I guess an easier way to see whether your patch works: Does the function
browser work before you are running? Or you could simply type in the
name of a file or function in the combo boxes in the tool bar.

Keith

Re: Problem with "file" command from CVS_HEAD

[Steven Johnson]

Keith Seitz wrote:

>On Tue, 2005-05-17 at 00:04 -1100, Accounts wrote:
>
>  
>
>>I Believe this is the correct thing to do.
>>    
>>
>
>Hmm. I'm not so sure... So what happens if you're not running and you
>type something like "tk gdb_loc main". Does it return something useful?
>
>  
>
Yes, i was re-considering this problem this morning.

>The problem is, of course, that there is no specific way to pass an
>error like this to the UI (the error is really an ignorable one in this
>case). We don't want invocations of gdb_loc to fail because we don't
>have a running target. I guess we could always pass some sort of fixed
>constant string (like "NOT_RUNNING" or something) instead of the PC
>value to indicate no registers or not running...
>  
>
The thought occured, that in the case of a non-running target, maybe the 
best reply to gdb_loc for a $PC is the value of the entry point for the 
program in question.  Its at least a sane default, and is not generating 
an error.

the code would then do something like the case where objc=2, but for the 
fixed address of entry point.

>I guess an easier way to see whether your patch works: Does the function
>browser work before you are running? Or you could simply type in the
>name of a file or function in the combo boxes in the tool bar.
>  
>
Well thats the killer, at the moment I am having problems with the 
function browser, and i dont know if its my patch or not.  The reason 
is, I cant test the function browser before i do the "file" command, 
because i have no functions to browse.  And when i do execute "file" i 
segfault, without my patch.  So its not possible for me to test it.

But i was thinking if i return the address of the entry_point as $pc in 
this case for gdb_loc that at least that might be a more sensible answer.

Now all i need to do to test it is work out how to get the address of 
the entry_point :)

another alternative is the address of "main" but an embedded program may 
not have a "main" as there is no real requirement in an embedded system 
to have a function with this name.

Also, it occured that i should include in the patch a patch of the 
Changelog.  Thats the correct protocol is it not.

Steven Johnson

Re: Problem with "file" command from CVS_HEAD

[Steven Johnson]

[-- Attachment #1: Type: text/plain, Size: 4442 bytes --]

OK,

Take 2.

The following patch provides "entry_point" as the PC if Insight has not 
connected to the target.  This seems a much better solution than my 
previous attempt, as it doesnt trigger an error, and so the TCL Code 
doesnt need to catch it any more than it did before my change.

Behaviour I now experience, which I feel are different problems:

1. If i execute "file" from a gdb script, sourced by --command:
     1.a) The source window comes up with the entry point highlighted. OK.
     1.b) I do not have the 3 Drop downs present under the button bar 
for file, function and mode. BAD
     1.c) I get a pop up (a lot) with the message: (Internal error: pc 
0x0 in read in psymtab, but not in symtab.). BAD
     Note, my entry point is the address 0x00000000.  The pop up occurs 
so much, it makes the interface unusable.
     Sometimes the address it complains about is 0x00000100.  This is a 
problem from GDB, and whatever it is will
     need to be suppressed, either by the code that puts the pop up up, 
(probably preferable, as I know from past
     experience that the GDB maintainers arent that interested that this 
message when it occurs usually means (at least
     in my experience)
     a) Nothing is wrong that is going to cause GDB too many problems, 
and b) it occurs so often to impede the functional
     use of GDB.  I am preparing a patch to allow this warning to be 
disabled, for those who really arent interested if
     psymtab matches symtab or not, because it is outside of their 
control (like the normal end user).  But I think i should
     also put a filter in Insight for it, so the popup doesnt happen, 
either way.
2. If i execute "file" from inside insight, by the menu, or by typing it 
in the Console window (effects are the same):
    2.a)Before i execute it, after insight starts, the 3 Drop downs 
present under the button bar for file, function and mode are present.
    2.b)When i execute it i get an error "This file can not be found or 
does not contain debugging information."
           Also, while the error box is shown, the first drop down (file 
list) shows "xxx,"
    2.c) if i press ok, then the error closes, xxx, disappears from the 
file list, but no file is displayed, including the entry point.
    2.d) if i then select a file in the first drop down, i see that file 
listed, but i get my error from 1.c) above.
    2.e) if i then select a function, i get the error from 2.b) again, 
including xxx, shown in the first drop down.
    2.f) when i select ok, i get "Error: expected integer but got 
"read," i then have an option for a stacktrace:
    2.g) the stack trace if selected is:

expected integer but got "read,"
    while executing
"gdb_CA_to_TAS $addr"
    (object "::.srcwin0.srcwin" method "::SrcWin::location" body line 46)
    invoked from within
"location BROWSE_TAG $result"
    (object "::.srcwin0.srcwin" method "::SrcWin::goto_func" body line 19)
    invoked from within
"::.srcwin0.srcwin goto_func 
.srcwin0.srcwin.container.pane1.childsite.con.func CountDisplayableJackpots"
    (in namespace inscope "::SrcWin" script line 1)
    invoked from within
"namespace inscope ::SrcWin {::.srcwin0.srcwin goto_func} 
.srcwin0.srcwin.container.pane1.childsite.con.func CountDisplayableJackpots"
    ("uplevel" body line 1)
    invoked from within
"uplevel \#0 $options(-command) $args"
    (procedure "CallCommand" line 9)
    invoked from within
"CallCommand $w $newValue"
    (procedure "::combobox::SetValue" line 33)
    invoked from within
"::combobox::SetValue $widgets(this) $data"
    (procedure "::combobox::Select" line 8)
    invoked from within
"::combobox::Select .srcwin0.srcwin.container.pane1.childsite.con.func  
[.srcwin0.srcwin.container.pane1.childsite.con.func.top.list nearest 13]"
    (command bound to event)errorCode is NONE

I think these only now occur, because  I am getting past the segfault, 
the only behaviour which differs in the above from my previous fix is 
1.a) which in the previous fix didnt show the entry point, it showed no 
source at all, but otherwise everything else still occured, so I dont 
think this fix is responsible for these problems.

I will continue to investigate these issues.  Once ive tracked them 
down, and i can see for sure they are unrelated or at least not cause 
and effect, i will resubmit this patch with appropriate changelog 
entries, if no one has any negative comments.

Steven Johnson


[-- Attachment #2: insight-6.3.50-gdb_loc-no-registers.patch --]
[-- Type: text/x-patch, Size: 1072 bytes --]

diff -Naur gdb-6.3/gdb/gdbtk/generic/gdbtk-cmds.c gdb-6.3-modified/gdb/gdbtk/generic/gdbtk-cmds.c
--- gdb-6.3/gdb/gdbtk/generic/gdbtk-cmds.c	2005-05-15 21:49:09.000000000 -1100
+++ gdb-6.3-modified/gdb/gdbtk/generic/gdbtk-cmds.c	2005-05-17 16:46:58.164964427 -1100
@@ -2114,8 +2114,18 @@
 
   if (objc == 1)
     {
-      if (deprecated_selected_frame
-	  && (get_frame_pc (deprecated_selected_frame) != read_pc ()))
+      /* This function can be called, before the target is properly
+         set-up, the following prevents an error, by trying to
+	 read_pc when there is no pc to read. It defaults pc, 
+         before the target is connected to the entry point of the
+         program */
+      if (!target_has_registers)
+        {
+	  pc = entry_point_address ();
+	  sal = find_pc_line (pc, 0);
+	}  
+      else if (deprecated_selected_frame
+	       && (get_frame_pc (deprecated_selected_frame) != read_pc ()))
         {
           /* Note - this next line is not correct on all architectures.
 	     For a graphical debugger we really want to highlight the 

Re: Problem with "file" command from CVS_HEAD

[Steven Johnson]

[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]

OK,

Take 3.

Now i believe this is the final patch required.

I have added comments for Changelog, and i believe i have tracked all 
issues i previously listed.

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.

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.

All of the other problem were because I had a number of GDB debug flags 
set to 1.  The messages generated by these debug flags being enabled 
confused insight and produced the rest of my reported problems.

That was certainly "a trap for young players".  And took me most of the 
night to identify.  Its far from intuitive that debug flags will cause 
bugs in their own right.

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.

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?

Steven Johnson



[-- Attachment #2: insight-6.3.50-gdb_loc-no-registers-V3.patch --]
[-- Type: text/x-patch, Size: 2590 bytes --]

diff -Naur gdb-6.3/gdb/gdbtk/ChangeLog gdb-6.3-modified/gdb/gdbtk/ChangeLog
--- gdb-6.3/gdb/gdbtk/ChangeLog	2005-05-15 21:49:09.000000000 -1100
+++ gdb-6.3-modified/gdb/gdbtk/ChangeLog	2005-05-18 01:29:21.811674459 -1100
@@ -1,3 +1,14 @@
+2005-05-18  Steven Johnson <sjohnson@sakuraindustries.com>
+
+	* generic/gdbtk-cmds.c (gdb_loc): Handle gdb_loc called before
+	remote target connected, where gdb_loc is to return $pc, default
+	$pc to entry point of program in question.
+	* library/interface.tcl (gdbtk_tcl_warning): Filter GDB Warning:
+	(Internal error: [address] in read in psymtab, but not in symtab)
+	When it occurs, it occurs excessively and otherwise makes 
+	debugging all but impossible.  There is also little an end user
+	can do with the information presented by the Warning.
+
 2005-04-28  Ben Elliston  <bje@au.ibm.com>
 
 	* generic/gdbtk-interp.c (gdbtk_interpreter_exec): Return struct
diff -Naur gdb-6.3/gdb/gdbtk/generic/gdbtk-cmds.c gdb-6.3-modified/gdb/gdbtk/generic/gdbtk-cmds.c
--- gdb-6.3/gdb/gdbtk/generic/gdbtk-cmds.c	2005-05-15 21:49:09.000000000 -1100
+++ gdb-6.3-modified/gdb/gdbtk/generic/gdbtk-cmds.c	2005-05-18 01:18:58.650064928 -1100
@@ -2114,8 +2114,18 @@
 
   if (objc == 1)
     {
-      if (deprecated_selected_frame
-	  && (get_frame_pc (deprecated_selected_frame) != read_pc ()))
+      /* This function can be called, before the target is properly
+         set-up, the following prevents an error, by trying to
+         read_pc when there is no pc to read. It defaults pc, 
+         before the target is connected to the entry point of the
+         program */
+      if (!target_has_registers)
+        {
+          pc = entry_point_address ();
+          sal = find_pc_line (pc, 0);
+        }  
+      else if (deprecated_selected_frame
+	       && (get_frame_pc (deprecated_selected_frame) != read_pc ()))
         {
           /* Note - this next line is not correct on all architectures.
 	     For a graphical debugger we really want to highlight the 
diff -Naur gdb-6.3/gdb/gdbtk/library/interface.tcl gdb-6.3-modified/gdb/gdbtk/library/interface.tcl
--- gdb-6.3/gdb/gdbtk/library/interface.tcl	2005-05-15 21:49:09.000000000 -1100
+++ gdb-6.3-modified/gdb/gdbtk/library/interface.tcl	2005-05-18 01:17:22.266403377 -1100
@@ -364,6 +364,7 @@
 # add the message at the beginning of the switch followed by - 
 
   switch -regexp $message {
+        "\(Internal error:.*in read in psymtab, but not in symtab\)" -
         "Unable to find dynamic linker breakpoint function.*" {return}
         default {show_warning $message}
        }

Re: Problem with "file" command from CVS_HEAD

[Keith Seitz]

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

Re: [patch/ping] Problem with "file" command from CVS_HEAD

[Steven Johnson]

[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]

OK,

Take 3.

Now i believe this is the final patch required.

I have added comments for Changelog, and i believe i have tracked all
issues i previously listed.

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.

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.

All of the other problem were because I had a number of GDB debug flags
set to 1.  The messages generated by these debug flags being enabled
confused insight and produced the rest of my reported problems.

That was certainly "a trap for young players".  And took me most of the
night to identify.  Its far from intuitive that debug flags will cause
bugs in their own right.

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.

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?

Steven Johnson




[-- Attachment #2: insight-6.3.50-gdb_loc-no-registers-V3.patch --]
[-- Type: text/x-patch, Size: 2591 bytes --]

diff -Naur gdb-6.3/gdb/gdbtk/ChangeLog gdb-6.3-modified/gdb/gdbtk/ChangeLog
--- gdb-6.3/gdb/gdbtk/ChangeLog	2005-05-15 21:49:09.000000000 -1100
+++ gdb-6.3-modified/gdb/gdbtk/ChangeLog	2005-05-18 01:29:21.811674459 -1100
@@ -1,3 +1,14 @@
+2005-05-18  Steven Johnson <sjohnson@sakuraindustries.com>
+
+	* generic/gdbtk-cmds.c (gdb_loc): Handle gdb_loc called before
+	remote target connected, where gdb_loc is to return $pc, default
+	$pc to entry point of program in question.
+	* library/interface.tcl (gdbtk_tcl_warning): Filter GDB Warning:
+	(Internal error: [address] in read in psymtab, but not in symtab)
+	When it occurs, it occurs excessively and otherwise makes 
+	debugging all but impossible.  There is also little an end user
+	can do with the information presented by the Warning.
+
 2005-04-28  Ben Elliston  <bje@au.ibm.com>
 
 	* generic/gdbtk-interp.c (gdbtk_interpreter_exec): Return struct
diff -Naur gdb-6.3/gdb/gdbtk/generic/gdbtk-cmds.c gdb-6.3-modified/gdb/gdbtk/generic/gdbtk-cmds.c
--- gdb-6.3/gdb/gdbtk/generic/gdbtk-cmds.c	2005-05-15 21:49:09.000000000 -1100
+++ gdb-6.3-modified/gdb/gdbtk/generic/gdbtk-cmds.c	2005-05-18 01:18:58.650064928 -1100
@@ -2114,8 +2114,18 @@
 
   if (objc == 1)
     {
-      if (deprecated_selected_frame
-	  && (get_frame_pc (deprecated_selected_frame) != read_pc ()))
+      /* This function can be called, before the target is properly
+         set-up, the following prevents an error, by trying to
+         read_pc when there is no pc to read. It defaults pc, 
+         before the target is connected to the entry point of the
+         program */
+      if (!target_has_registers)
+        {
+          pc = entry_point_address ();
+          sal = find_pc_line (pc, 0);
+        }  
+      else if (deprecated_selected_frame
+	       && (get_frame_pc (deprecated_selected_frame) != read_pc ()))
         {
           /* Note - this next line is not correct on all architectures.
 	     For a graphical debugger we really want to highlight the 
diff -Naur gdb-6.3/gdb/gdbtk/library/interface.tcl gdb-6.3-modified/gdb/gdbtk/library/interface.tcl
--- gdb-6.3/gdb/gdbtk/library/interface.tcl	2005-05-15 21:49:09.000000000 -1100
+++ gdb-6.3-modified/gdb/gdbtk/library/interface.tcl	2005-05-18 01:17:22.266403377 -1100
@@ -364,6 +364,7 @@
 # add the message at the beginning of the switch followed by - 
 
   switch -regexp $message {
+        "\(Internal error:.*in read in psymtab, but not in symtab\)" -
         "Unable to find dynamic linker breakpoint function.*" {return}
         default {show_warning $message}
        }

Re: [patch/ping] Problem with "file" command from CVS_HEAD

[Steven Johnson]

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]

Posted some time ago, a frinedly ping :)

OK,

Take 3.

Now i believe this is the final patch required.

I have added comments for Changelog, and i believe i have tracked all
issues i previously listed.

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.

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.

All of the other problem were because I had a number of GDB debug flags
set to 1.  The messages generated by these debug flags being enabled
confused insight and produced the rest of my reported problems.

That was certainly "a trap for young players".  And took me most of the
night to identify.  Its far from intuitive that debug flags will cause
bugs in their own right.

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.

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?

Steven Johnson





[-- Attachment #2: insight-6.3.50-gdb_loc-no-registers-V3.patch --]
[-- Type: text/x-patch, Size: 2592 bytes --]

diff -Naur gdb-6.3/gdb/gdbtk/ChangeLog gdb-6.3-modified/gdb/gdbtk/ChangeLog
--- gdb-6.3/gdb/gdbtk/ChangeLog	2005-05-15 21:49:09.000000000 -1100
+++ gdb-6.3-modified/gdb/gdbtk/ChangeLog	2005-05-18 01:29:21.811674459 -1100
@@ -1,3 +1,14 @@
+2005-05-18  Steven Johnson <sjohnson@sakuraindustries.com>
+
+	* generic/gdbtk-cmds.c (gdb_loc): Handle gdb_loc called before
+	remote target connected, where gdb_loc is to return $pc, default
+	$pc to entry point of program in question.
+	* library/interface.tcl (gdbtk_tcl_warning): Filter GDB Warning:
+	(Internal error: [address] in read in psymtab, but not in symtab)
+	When it occurs, it occurs excessively and otherwise makes 
+	debugging all but impossible.  There is also little an end user
+	can do with the information presented by the Warning.
+
 2005-04-28  Ben Elliston  <bje@au.ibm.com>
 
 	* generic/gdbtk-interp.c (gdbtk_interpreter_exec): Return struct
diff -Naur gdb-6.3/gdb/gdbtk/generic/gdbtk-cmds.c gdb-6.3-modified/gdb/gdbtk/generic/gdbtk-cmds.c
--- gdb-6.3/gdb/gdbtk/generic/gdbtk-cmds.c	2005-05-15 21:49:09.000000000 -1100
+++ gdb-6.3-modified/gdb/gdbtk/generic/gdbtk-cmds.c	2005-05-18 01:18:58.650064928 -1100
@@ -2114,8 +2114,18 @@
 
   if (objc == 1)
     {
-      if (deprecated_selected_frame
-	  && (get_frame_pc (deprecated_selected_frame) != read_pc ()))
+      /* This function can be called, before the target is properly
+         set-up, the following prevents an error, by trying to
+         read_pc when there is no pc to read. It defaults pc, 
+         before the target is connected to the entry point of the
+         program */
+      if (!target_has_registers)
+        {
+          pc = entry_point_address ();
+          sal = find_pc_line (pc, 0);
+        }  
+      else if (deprecated_selected_frame
+	       && (get_frame_pc (deprecated_selected_frame) != read_pc ()))
         {
           /* Note - this next line is not correct on all architectures.
 	     For a graphical debugger we really want to highlight the 
diff -Naur gdb-6.3/gdb/gdbtk/library/interface.tcl gdb-6.3-modified/gdb/gdbtk/library/interface.tcl
--- gdb-6.3/gdb/gdbtk/library/interface.tcl	2005-05-15 21:49:09.000000000 -1100
+++ gdb-6.3-modified/gdb/gdbtk/library/interface.tcl	2005-05-18 01:17:22.266403377 -1100
@@ -364,6 +364,7 @@
 # add the message at the beginning of the switch followed by - 
 
   switch -regexp $message {
+        "\(Internal error:.*in read in psymtab, but not in symtab\)" -
         "Unable to find dynamic linker breakpoint function.*" {return}
         default {show_warning $message}
        }

Re: [patch/ping] Problem with "file" command from CVS_HEAD

[Keith Seitz]

On Tue, 2005-06-07 at 00:21 -1100, Steven Johnson wrote:
> Posted some time ago, a frinedly ping :)

I think I said a while ago that I wasn't really happy with not
displaying internal errors. I would strongly prefer the warning be
marked ignorable. Actually, we should change show_warning to ALWAYS
check for an ignorable warning.

That said, I will commit the other part of the patch, which has nothing
to do with this warning stuff.

Keith 

Re: GDB Internal Errors/other messages.

[Steven Johnson]

Keith Seitz wrote:

>I think I said a while ago that I wasn't really happy with not
>displaying internal errors. I would strongly prefer the warning be
>marked ignorable. Actually, we should change show_warning to ALWAYS
>check for an ignorable warning.
>  
>
I can respect that.

However, what i have experienced is if GDB sends messages through 
insight that insight isnt expecting.  Like Internal Errors, or even the 
verbose debug flags, then parts of Insight break, depending on when the 
error or message is sent.  It was far from intuitive to me why these 
popus were causing things like the symbol browser not to display.  Any 
hints? because i think its a bug that should be fixed, and id like to 
fix it! 

Also, instead of them popping up, which can be really really really 
annoying, how about a feature change, so that errors/internal errors, 
etc, are routed to their own list window, and an icon appears on the 
main window somewhere, indicating errors have occured.  Click the icon 
and you go to the error/message list view.  Its just that if you get 
some of these errors, like the PSymTab one i am getting, it can make 
debugging all but impossible, because it occurs so much.

Obviously this is a bit of work to implement, so id prefer to hash the 
issues out before wasting my time writing unaceptable code.

Steven

Re: GDB Internal Errors/other messages.

[Keith Seitz]

On Tue, 2005-06-07 at 09:47 -1100, Steven Johnson wrote:
> However, what i have experienced is if GDB sends messages through 
> insight that insight isnt expecting.  Like Internal Errors, or even the 
> verbose debug flags, then parts of Insight break, depending on when the 
> error or message is sent.  It was far from intuitive to me why these 
> popus were causing things like the symbol browser not to display.  Any 
> hints? because i think its a bug that should be fixed, and id like to 
> fix it! 

Warning messages shouldn't interfere with the way insight works.
[Setting some internal gdb variable for debugging might, since gdb does
not have a generic debugging channel -- it just uses printf_filtered and
friends.] This is another one of those places where gdb should be fixed.

> Also, instead of them popping up, which can be really really really 
> annoying, how about a feature change, so that errors/internal errors, 
> etc, are routed to their own list window, and an icon appears on the 
> main window somewhere, indicating errors have occured.  Click the icon 
> and you go to the error/message list view.  Its just that if you get 
> some of these errors, like the PSymTab one i am getting, it can make 
> debugging all but impossible, because it occurs so much.

I agree, but for some class of fatal errors, we do want the dialog. I
guess this should only really happen when GDB asks the whole "continue
session? dump core?" questions. I believe those more serious "warnings"
go through a different route, so I guess that we could really just map
these internal error messages somewhere else (like a "warnings" window
or just insert them in the console window).

So now the question is should we just map every message that starts
"Internal error" to this alternate place? Would we miss anything? I
suspect not...

So, you've convinced me that your previous patch should be used in some
form. I'll check that in now, rerouting the message to the console
window. If you want to do the work of the whole warning window thing,
just submit when you're done.

Keith

[PATCH]: Ignore warnings (was Re: GDB Internal Errors/other messages.)

[Keith Seitz]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

On Mon, 2005-06-06 at 17:48 -0700, Keith Seitz wrote:
> So, you've convinced me that your previous patch should be used in some
> form. I'll check that in now, rerouting the message to the console
> window. If you want to do the work of the whole warning window thing,
> just submit when you're done.

I've checked in the attached patch which does this for any warning that
starts with "Internal error" or "incomplete CFI". There are probably a
bunch more.

It reroutes the messages to the console.

Keith

ChangeLog
2005-06-06  Keith Seitz  <keiths@redhat.com>

        * library/interface.tcl (gdbtk_tcl_fputs_error): gdbtk_state is in the global
        namespace. Fix references.
        (gdbtk_tcl_fputs_log): Likewise.

        From Steven Johnson  <johnson@sakuraindustries.com>:
        * library/interface.tcl (gdbtk_tcl_warning): Filter some basic warnings
        from gdb - "incomplete CFI.." and "Internal error".



[-- Attachment #2: ignore-warnings.patch --]
[-- Type: text/x-patch, Size: 1592 bytes --]

Index: library/interface.tcl
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/library/interface.tcl,v
retrieving revision 1.53
diff -u -p -r1.53 interface.tcl
--- library/interface.tcl	27 Aug 2004 23:13:14 -0000	1.53
+++ library/interface.tcl	7 Jun 2005 01:07:19 -0000
@@ -365,6 +365,11 @@ proc gdbtk_tcl_warning {message} {
 
   switch -regexp $message {
         "Unable to find dynamic linker breakpoint function.*" {return}
+	"Internal error.*" { gdbtk_tcl_fputs_error $message }
+        "incomplete CFI.*" {
+	    puts "here i am"
+	    gdbtk_tcl_fputs_error $message
+	}
         default {show_warning $message}
        }
 }
@@ -435,7 +440,8 @@ proc echo {args} {
 # PROC: gdbtk_tcl_fputs_error - write an error message
 # ------------------------------------------------------------------
 proc gdbtk_tcl_fputs_error {message} {
-  if {[info exists gdbtk_state(console)] && $::gdbtk_state(console) != ""} {
+  if {[info exists ::gdbtk_state(console)] && $::gdbtk_state(console) != ""} {
+      puts "I am here, too"
     $::gdbtk_state(console) insert $message err_tag
     update
   }
@@ -445,7 +451,7 @@ proc gdbtk_tcl_fputs_error {message} {
 # PROC: gdbtk_tcl_fputs_log - write a log message
 # ------------------------------------------------------------------
 proc gdbtk_tcl_fputs_log {message} {
-  if {[info exists gdbtk_state(console)] && $::gdbtk_state(console) != ""} {
+  if {[info exists ::gdbtk_state(console)] && $::gdbtk_state(console) != ""} {
     $::gdbtk_state(console) insert $message log_tag
     update
   }

Re: [PATCH]: Ignore warnings (was Re: GDB Internal Errors/other messages.)

[Keith Seitz]

On Mon, 2005-06-06 at 18:12 -0700, Keith Seitz wrote:
> I've checked in the attached patch which does this for any warning that
> starts with "Internal error" or "incomplete CFI". There are probably a
> bunch more.

Of course, I'll whack the darn debug statements in it!

O:-)

Keith

Numerous Warnings for RTTI Symbol Not Found

[Vale Group]

When viewing the local variables in a program being debugged, Insight often
displays numerous popup GDB warning windows of the form:

RTTI symbol not found for class '<namespace name::derived class name>'

What causes those warnings to appear?
Is there something about the architecture of my program which causes these
warnings?
Does gdb still not understand namespaces?
Is it possible to suppress the warnings? (Each one must be individually
acknowledged to continue!)

All optimization is disabled.
I have used debugging switches -g, -ggdb and -g3 with the same results.

Insight Version: GNU gdb 6.3.50_2004-12-28-cvs (cygwin special) configured as
i686-pc-cygwin
gcc Version: 3.4.4
Cygwin Version: 1.5.17

Charles

Re: Numerous Warnings for RTTI Symbol Not Found

[Keith Seitz]

On Sat, 2005-06-11 at 16:52 -0700, Vale Group wrote:
> What causes those warnings to appear?

GDB still hasn't fixed these kinds of problems. I think most gdb
developers are so used to these little annoyances that they just ignore
them, which is easy to do when it just results in a line being printed
to the terminal.

> Is it possible to suppress the warnings? (Each one must be individually
> acknowledged to continue!)

Yes, edit gdb/gdbtk/library/interface.tcl. The procedure
"gdbtk_tcl_warning" contains a list of error messages which will simply
go to the console window without opening a dialog.

When you've done that, please submit a patch. For this small change, you
probably don't need to worry about an assignment if you don't have one.

Keith

Re: Numerous Warnings for RTTI Symbol Not Found

[Vale Group]

> Yes, edit gdb/gdbtk/library/interface.tcl. The procedure "gdbtk_tcl_warning"
contains a list of error messages which will simply go to the console window
without opening a dialog.

In my case that file would probably be
C:\cygwin\usr\share\insight1.0\interface.tcl

Shooting in the dark and without any prior experience in tcl, I added a line to
a copy of interface.tcl which banishes those annoying warnings. It appears that
my change was successful; now I can read local variables without interference.
Then I added another line to quash linker symbol warnings. By the way, the
warnings don't appear in the Insight console window either which is fine with
me.

> When you've done that, please submit a patch.

Here's a diff of the old and new files:

$ diff interface.tcl.old interface.tcl
367a368,369
>         "RTTI symbol not found for class *" {return}
>         "can't find linker symbol for virtual table *" {return}

> For this small change, you probably don't need to worry about an assignment if
you don't have one.

I don't understand what that means. You have ascribed to me a level of computer
knowledge unwarranted by the facts.

Thanks for your help, Keith. You are a wonderful human being.

Charles

Re: Numerous Warnings for RTTI Symbol Not Found

[Keith Seitz]

On Sun, 2005-06-12 at 14:46 -0700, Vale Group wrote:
> $ diff interface.tcl.old interface.tcl
> 367a368,369
> >         "RTTI symbol not found for class *" {return}
> >         "can't find linker symbol for virtual table *" {return}

I've committed this patch.

[BTW next time anyone asks for a diff, use "diff -u" -- it's a lot
easier to read]

Thanks for the patch! :v)
Keith