From mboxrd@z Thu Jan  1 00:00:00 1970
From: Steven Johnson <sbjohnson@ozemail.com.au>
To: insight@sources.redhat.com
Subject: 2 Segfaults in Insights (Latest CVS)
Date: Wed, 11 Oct 2000 00:54:00 -0000
Message-id: <39E418FB.46E1EA66@ozemail.com.au>
X-SW-Source: 2000-q4/msg00049.html

I am experiencing 2 Segfaults in Insight. 1 I have tracked a cause for, the
other I havent. Before I get into details I will spout the preliminaries.

Host: Mandrake Linux 7.0 (Kernel 2.2.14)
Insight Version: CVS as of today.
configuration: ../src/configure --target=powerpc-eabi 
                                --program-prefix=insight-ppc
                                --prefix=/opt/powerpc-gdb

GCC Version: 2.95.2

Details:
Segfault 1: 

Start Insight     : OK
Connect to Target : OK
Download          : Segfault.

I am starting insight with
/opt/powerpc-gdb/bin/insight-ppc-gdb                    
                                    --command=mpc860-gdb-init

The command file defines some hooks so I can operate my target hardware
properly. Especially with regard to loading the program (I am running out of
flash!).

When I connect (using the standard dialog). I am connecting to a server for my
BDM Interface to the PowerPC MPC860 Board. It is running on the same computer
as Insight, and it communicates using the standard GDB Remote protocol. I
Connect to localhost:2345. 

When I choose download Insight almost immediately segfaults in "gdbtypes.c,
line 1060" This is not the problem however, it is the symptom. A Stack trace
gives me a trace through values.c, valops.c, eval.c and eventually to the
function set_command in printcmd.c (line 1041).

This works fine if I start gdb with the --nw option BTW.

What I "think" the problem is:

Insight appears to hook all "set" operations when it is executing a gui command
such as download. It does this, so that any variables that are changed by the
command are updated on the display. My script adds a hook to the load
operation. The hook writes to a register with:

set $ictrl=0x7

I need this because of peculiarities with the way I need to operate my
hardware. Insight executes this command on the target properly. It then
interprets the SET operation. Looks up symbol $ictrl (which doesn't exist, its
a register not a symbol of the program.) tries to set it's local value to 0x7
and segfaults because the pointer to the symbol is invalid crap. GDB without
Insight doesn't do it because it does not post interpret the set operations.

set_command is the culprit that does this. I have tested my hypothesis by
commenting out the expression evaluation in set_command. When I do this,
loading works fine. This is obviously not the correct fix. I can see what
Insight is attempting to achieve and it is valid. Im not sure how to fix the
case where the symbol doesn't exist. Any input would be appreciated as I would
really like to get this fixed.

I think it could be forced on any Insight by creating a hook on load that
updates a register to some arbitrary value. For example:

define hook-load
  set $eax=0x01
  set $eax=0x00
end

I did it twice to defeat the register caching mechanism for the purposes of the
test. (If the first write doesn't do anything, the second will.) I believe this
will segfault Insight everytime (NOTE: I haven't tested this on an intel target
myself)

The second segfault is currently not giving me much information at all:
Program received SIGSEGV,segmentation fault.
0x7d68375 in ?? ()
(gdb) info stack
#0 0x7d68375 in ?? ()
Cannot access memory address 0x6f74746e
(gdb)

This occurs when I set a breakpoint, run to it, and then try and clear it. (I
need to do more testing.) I have mentioned it to see if it is already known, or
unique to me.

Anyway, any comments on this stuff?

Steven Johnson