Re: Problem with "file" command from CVS_HEAD

[Steven Johnson <sjohnson@sakuraindustries.com>]

[-- 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 ()))
         {