z8k simulator broken

z8k simulator broken

[Daniel Jacobowitz]

Did you ever get a chance to look at the z8k sim problem?  It seems that the
problem is that it uses the idx to generate the names of functions, but your
changes to "Generate idx as gas needs it" broke that.

Here's what I'm using; it builds, but I haven't really tested the simulator
yet.  Someone tell me again why I'm doing this?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Index: writecode.c
===================================================================
RCS file: /cvs/src/src/sim/z8k/writecode.c,v
retrieving revision 1.3
diff -u -p -r1.3 writecode.c
--- writecode.c	6 Jun 2002 15:50:50 -0000	1.3
+++ writecode.c	15 Jan 2003 04:27:10 -0000
@@ -187,7 +187,7 @@ lookup_inst (what)
 	    }
 	  if (nibl_matched)
 	    {
-	      z8k_inv_list[what] = ptr->idx;
+	      z8k_inv_list[what] = ptr - z8k_table;
 	      break; /* while */
 	    }
 	  ptr++;
@@ -1550,7 +1550,7 @@ mangle (p, shortcut, value)
     }
   else
     {
-      emit ("int <fop>_%d(context,pc,iwords0)\n", p->idx);
+      emit ("int <fop>_%d(context,pc,iwords0)\n", p - z8k_table);
       emit ("int iwords0;\n");
     }
   emit ("sim_state_type *context;\n");
@@ -1668,7 +1668,7 @@ build_list (i)
 
   if (!p)
     return;
-  add_to_list (&list[p->idx], i);
+  add_to_list (&list[p - z8k_table], i);
 }
 
 int
@@ -1807,7 +1807,7 @@ main (ac, av)
 #endif
 	  if (p != NULL)
 	    {
-	      printf ("%d", p->idx);
+	      printf ("%d", p - z8k_table);
 	    }
 	  else
 	    printf ("400");

Re: z8k simulator broken

[Alan Modra]

On Tue, Jan 14, 2003 at 11:28:18PM -0500, Daniel Jacobowitz wrote:
> Did you ever get a chance to look at the z8k sim problem?

No, I didn't.  Andrew told me that it wasn't that important, and for me
to go and fix something else.  Haven't done the "something else",
either.  :)  Knowing what I changed, your patch looks good to me.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: z8k simulator broken

[Daniel Jacobowitz]

On Wed, Jan 15, 2003 at 03:15:45PM +1030, Alan Modra wrote:
> On Tue, Jan 14, 2003 at 11:28:18PM -0500, Daniel Jacobowitz wrote:
> > Did you ever get a chance to look at the z8k sim problem?
> 
> No, I didn't.  Andrew told me that it wasn't that important, and for me
> to go and fix something else.  Haven't done the "something else",
> either.  :)  Knowing what I changed, your patch looks good to me.

For the curious (why would you be curious?  I don't know.  I don't even
know why I started doing this!) I don't know if this simulator was ever
able to run GDB tests or simple newlib binaries but my guess is not
recently.

A z8002 binary (gdb.base/break) has a .text section of size 0xeb24 or
so.  The heap is 0x5000, the stack is 0x1000, and AFAICT a z8002 has
only 0x10000 memory.

A z8001 has much more memory available but only in 64k segments, and
.text is:
  0 .text         00019a94  00000000  00000000  00000120  2**1
                  CONTENTS, ALLOC, LOAD, CODE

i.e. much more than the one segment it can use.


I was trying to multi-arch the z8k on a lark, but it's not enough of a
lark to try to get around _that_.  Let it die.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: z8k simulator broken

[Andrew Cagney]

> For the curious (why would you be curious?  I don't know.  I don't even
> know why I started doing this!) I don't know if this simulator was ever
> able to run GDB tests or simple newlib binaries but my guess is not
> recently.
> 
> A z8002 binary (gdb.base/break) has a .text section of size 0xeb24 or
> so.  The heap is 0x5000, the stack is 0x1000, and AFAICT a z8002 has
> only 0x10000 memory.
> 
> A z8001 has much more memory available but only in 64k segments, and
> .text is:
>   0 .text         00019a94  00000000  00000000  00000120  2**1
>                   CONTENTS, ALLOC, LOAD, CODE
> 
> i.e. much more than the one segment it can use.
> 
> 
> I was trying to multi-arch the z8k on a lark, but it's not enough of a
> lark to try to get around _that_.  Let it die.

Hmm, I'll file this one away :-)

More evidence supporting the hard-nosed requirement that someone doing a 
multi-arch must ensure that the before/after code actually works.  GDB 
isn't in the business of trying to preserve dead code.

Andrew