Patch to provide m68k simulator to gdb

Patch to provide m68k simulator to gdb

[Will Cohen]

DJ Delorie and I have integrated the m68k emulator from the Un*x Amiga
Emulator (UAE) with gdb. UAE is GPL'ed software. The ChangeLog entries
and patch file are attached to this mail.  I would like to get this
incorporated into gdb. Other people might find this patch useful.

-Will Cohen
2001-02-27  Will Cohen  <wcohen@redhat.com>

	* src/dejagnu/baseboards/m68k-sim.exp: New file.
	* src/gdb/config/m68k/monitor.mt (SIM_OBJS): Added.
	(SIM): Added.
	* src/sim/configure: Added entry for m68k.
	* src/sim/configure.in: Added entry for m68k.


In sim/m68k:

2001-02-27  Will Cohen  <wcohen@redhat.com>

	* ChangeLog: New file.
	* README: New file.
	* Makefile.in: New file.
	* compiler.h: New file.
	* config.h: New file.
	* config.in: New file.
	* configure: New file.
	* gencpu.c: New file.
	* missing.c: New file.
	* custom.h: New file.
	* fpp.c: New file.
	* include/autoconf.h: New file.
	* include/debug.h: New file.
	* include/ersatz.h: New file.
	* include/memory.h: New file.
	* include/options.h: New file.
	* include/readcpu.h: New file.
	* include/sysdeps.h: New file.
	* include/uae.h: New file.
	* include/uaeexe.h: New file.
	* include/zfile.h: New file.
	* interp.c: New file.
	* machdep/m68k.h: New file.
	* machdep/maccess.h: New file.
	* machdep/rpt.h: New file.
	* md-fpp.h: New file.
 	* memory.c: New file.
	* newcpu.c: New file.
	* newcpu.h: New file.
	* readcpu.c: New file.
	* support.c: New file.
	* sysconfig.h: New file.
	* table68k: New file.
	* target.h: New file.
	* build68k.c: New file.
From taylor@cygnus.com Tue Feb 27 15:11:00 2001
From: David Taylor <taylor@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: [RFA] gdb testsuite changes
Date: Tue, 27 Feb 2001 15:11:00 -0000
Message-id: <200102272311.SAA18198@texas.cygnus.com>
X-SW-Source: 2001-02/msg00491.html
Content-length: 6737

These changes were motivated by a port of gdb to target an 8 bit
processor with 2 byte integers, no C++, no long long, and very limited
memory.

ChangeLog entry:

	* gdb.base/annota1.exp: Move test of isnative to earlier in the
 	file -- to prevent failing when the compile fails but we have no
 	intention of running the tests anyway.

	* gdb.base/long_long.exp: Test target_info for no_long_long, skip
	tests if set.

	* gdb.base/maint.exp: Support 2 byte integers as well as 4 byte
 	integers.

	* gdb.c++/ctti.exp: Skip tests if skip_cplus_tests returns true.
	* gdb.c++/namespace.exp: Ditto.

Okay to commit?

Index: testsuite/gdb.base/annota1.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/annota1.exp,v
retrieving revision 1.11
diff -c -r1.11 annota1.exp
*** annota1.exp	2000/06/26 02:07:19	1.11
--- annota1.exp	2001/02/27 22:56:40
***************
*** 25,30 ****
--- 25,40 ----
  }
  
  
+ # are we on a target board? If so, don't run these tests.
+ # note: this is necessary because we cannot use runto_main (which would
+ # work for remote targets too) because of the different prompt we get
+ # when using annotation level 2.
+ #
+ if ![isnative] then {
+     return 0
+ }
+ 
+ 
  #
  # test running programs
  #
***************
*** 37,52 ****
  
  if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug additional_flags=-w}] != "" } {
      gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
- }
- 
- 
- # are we on a target board? If so, don't run these tests.
- # note: this is necessary because we cannot use runto_main (which would
- # work for remote targets too) because of the different prompt we get
- # when using annotation level 2.
- #
- if ![isnative] then {
-     return 0
  }
  
  
--- 47,52 ----
Index: testsuite/gdb.base/long_long.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/long_long.exp,v
retrieving revision 1.9
diff -c -r1.9 long_long.exp
*** long_long.exp	2000/03/14 06:47:51	1.9
--- long_long.exp	2001/02/27 22:56:40
***************
*** 1,4 ****
! # Copyright (C) 1997, 1998, 1999, 2000 Free Software Foundation, Inc.
  
  # This program is free software; you can redistribute it and/or modify
  # it under the terms of the GNU General Public License as published by
--- 1,4 ----
! # Copyright (C) 1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
  
  # This program is free software; you can redistribute it and/or modify
  # it under the terms of the GNU General Public License as published by
***************
*** 23,28 ****
--- 23,32 ----
  #
  if $tracelevel then {
  	strace $tracelevel
+ }
+ 
+ if [target_info exists no_long_long] {
+     return 0
  }
  
  set testfile long_long
Index: testsuite/gdb.base/maint.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/maint.exp,v
retrieving revision 1.8
diff -c -r1.8 maint.exp
*** maint.exp	2000/11/17 16:41:31	1.8
--- maint.exp	2001/02/27 22:56:41
***************
*** 1,4 ****
! # Copyright (C) 1998 Free Software Foundation, Inc.
  
  # This program is free software; you can redistribute it and/or modify
  # it under the terms of the GNU General Public License as published by
--- 1,4 ----
! # Copyright (C) 1998, 2001 Free Software Foundation, Inc.
  
  # This program is free software; you can redistribute it and/or modify
  # it under the terms of the GNU General Public License as published by
***************
*** 343,349 ****
  
  send_gdb "maint print type argc\n"
  gdb_expect  {
!         -re "type node $hex\r\nname .int. \\($hex\\)\r\ncode $hex \\(TYPE_CODE_INT\\)\r\nlength 4\r\nobjfile $hex\r\ntarget_type $hex\r\npointer_type $hex\r\nreference_type $hex\r\nflags $hex\r\nnfields 0 $hex\r\nvptr_basetype $hex\r\nvptr_fieldno -1\r\ntype_specific $hex\r\n$gdb_prompt $"\
                          { pass "maint print type" }
          -re ".*$gdb_prompt $"       { fail "maint print type" }
          timeout         { fail "(timeout) maint print type" }
--- 343,349 ----
  
  send_gdb "maint print type argc\n"
  gdb_expect  {
!         -re "type node $hex\r\nname .int. \\($hex\\)\r\ncode $hex \\(TYPE_CODE_INT\\)\r\nlength \[24\]\r\nobjfile $hex\r\ntarget_type $hex\r\npointer_type $hex\r\nreference_type $hex\r\nflags $hex\r\nnfields 0 $hex\r\nvptr_basetype $hex\r\nvptr_fieldno -1\r\ntype_specific $hex\r\n$gdb_prompt $"\
                          { pass "maint print type" }
          -re ".*$gdb_prompt $"       { fail "maint print type" }
          timeout         { fail "(timeout) maint print type" }
cvs server: Diffing testsuite/gdb.c++
Index: testsuite/gdb.c++/ctti.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.c++/ctti.exp,v
retrieving revision 1.3
diff -c -r1.3 ctti.exp
*** ctti.exp	2000/06/12 12:46:56	1.3
--- ctti.exp	2001/02/27 22:56:42
***************
*** 1,4 ****
! # Copyright (C) 1998 Free Software Foundation, Inc.
  
  # This program is free software; you can redistribute it and/or modify
  # it under the terms of the GNU General Public License as published by
--- 1,4 ----
! # Copyright (C) 1998, 2001 Free Software Foundation, Inc.
  
  # This program is free software; you can redistribute it and/or modify
  # it under the terms of the GNU General Public License as published by
***************
*** 29,34 ****
--- 29,35 ----
          strace $tracelevel
  }
  
+ if { [skip_cplus_tests] } { continue }
  
  # Check to see if we have an executable to test.  If not, then either we
  # haven't tried to compile one, or the compilation failed for some reason.
Index: testsuite/gdb.c++/namespace.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.c++/namespace.exp,v
retrieving revision 1.3
diff -c -r1.3 namespace.exp
*** namespace.exp	2000/12/20 14:34:27	1.3
--- namespace.exp	2001/02/27 22:56:42
***************
*** 1,4 ****
! # Copyright (C) 1997, 1998 Free Software Foundation, Inc.
  
  # This program is free software; you can redistribute it and/or modify
  # it under the terms of the GNU General Public License as published by
--- 1,4 ----
! # Copyright (C) 1997, 1998, 2001 Free Software Foundation, Inc.
  
  # This program is free software; you can redistribute it and/or modify
  # it under the terms of the GNU General Public License as published by
***************
*** 35,40 ****
--- 35,41 ----
  set prms_id 0
  set bug_id 0
  
+ if { [skip_cplus_tests] } { continue }
  
  set testfile "namespace"
  set srcfile ${testfile}.cc

Re: Patch to provide m68k simulator to gdb

[J.T. Conklin]

>>>>> "Will" == Will Cohen <wcohen@redhat.com> writes:
Will> DJ Delorie and I have integrated the m68k emulator from the Un*x
Will> Amiga Emulator (UAE) with gdb. UAE is GPL'ed software. The
Will> ChangeLog entries and patch file are attached to this mail.  I
Will> would like to get this incorporated into gdb. Other people
Will> might find this patch useful.

Cool.  I've wanted a simulator for the m68k family for some time.

Some issues:

  * You say that UAE is GPL'd (and the UAE webpage also states this),
    but there is nothing in the source files that indicate this.  The
    files have the copyright statements of individual persons with no
    redistribution or licencing info.  I personally am very hesitant 
    to integrate such code as is.

  * I see from the UAE webpage, that the simulator can emulate a '000,
    '010, or '020.  For GDB, we'd want to add support for the '040 and
    '060; and perhaps the ColdFire.  While the onus is on us to add such
    features, do we have anything in place to keep divergence between 
    the two codebases to a minimum.  

  * I haven't looked at the FPU emulator, but if it doesn't do software
    FP, we'll have to re-implement it otherwise 96bit extended doubles
    won't work as expected.

  * The defines in sim/m68k/target.h don't seem to be used.  In fact,
    there appears to be quite a bit of code that isn't used.  This 
    could be cleaned up, but it won't be worth doing so unless our
    changes can be integrated into the master UAE sources (or we 
    decide to branch).


        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: Patch to provide m68k simulator to gdb

[Andrew Cagney]

"J.T. Conklin" wrote:
> 
> >>>>> "Will" == Will Cohen <wcohen@redhat.com> writes:
> Will> DJ Delorie and I have integrated the m68k emulator from the Un*x
> Will> Amiga Emulator (UAE) with gdb. UAE is GPL'ed software. The
> Will> ChangeLog entries and patch file are attached to this mail.  I
> Will> would like to get this incorporated into gdb. Other people
> Will> might find this patch useful.
> 
> Cool.  I've wanted a simulator for the m68k family for some time.
> 
> Some issues:
> 
>   * You say that UAE is GPL'd (and the UAE webpage also states this),
>     but there is nothing in the source files that indicate this.  The
>     files have the copyright statements of individual persons with no
>     redistribution or licencing info.  I personally am very hesitant
>     to integrate such code as is.

Ah yes.  Over the years, there have been many proposals to integrate an
m68k simulator into the sim source tree only in the past they ended up
tripping up on the GPL.  Sigh.  Hopefully this one can finally be
integrated.

While the copyright doesn't need to be transfered to the FSF the source
code does need a very clear copyright status.  If someone contributed a
significant change then that copyright would need to have clearly been
transfered.

As a an example PSIM is (C) me.  The contents of one file are (C) IBM. 
The ditribution of that file has been approved - I have bits of paper to
prove it :-)

	Andrew

Re: Patch to provide m68k simulator to gdb

[Andrew Cagney]

Below are some quick comment about things that are often missed when
integrating a new simulator.

--

New simulators use a header file (include/sim-XXX.h - eg
include/sim-d10v.h) as a way of avoiding magic numbers like:

sim_fetch_register()

+     case  0: case  1: case  2: case  3: case  4: case  5: case  6:
case  7:
+       /* address regs "a0", "a1", "a2", "a3", "a4", "a5", "fp", "sp"
*/
+     case  8: case  9: case 10: case 11: case 12: case 13: case 14:
case 15:
+       val = saved_state.regs[rn];

That header along with REGISTER_SIM_REGNO() make it possible to decouple
the simulators register numbers from GDBs.  Could the code please be
changed to at least use the header file.

--

I have a feeling that this code is implementing a number of
older/deprecated methods.  Have a look over include/remote-sim.h where
it clearly identifies deprecated interfaces.  For instance:

/* Single-step simulator with tracing enabled.
   THIS PROCEDURE IS DEPRECIATED.
   THIS PROCEDURE IS EVEN MORE DEPRECATED THAN SIM_SET_TRACE
   GDB and NRUN do not use this interface.

Make certain that you use `nrun.c'' and not the older ``run.c''.  Add
the line:

  # List of main object files for `run'.
  SIM_RUN_OBJS = nrun.o

to your Makefile.in.  It is probably why you implemented sim_trace()
et.al.


	Andrew

Re: Patch to provide m68k simulator to gdb

[Will Cohen]

Andrew Cagney wrote:
> 
> "J.T. Conklin" wrote:
> >
> > >>>>> "Will" == Will Cohen <wcohen@redhat.com> writes:
> > Will> DJ Delorie and I have integrated the m68k emulator from the Un*x
> > Will> Amiga Emulator (UAE) with gdb. UAE is GPL'ed software. The
> > Will> ChangeLog entries and patch file are attached to this mail.  I
> > Will> would like to get this incorporated into gdb. Other people
> > Will> might find this patch useful.
> >
> > Cool.  I've wanted a simulator for the m68k family for some time.
> >
> > Some issues:
> >
> >   * You say that UAE is GPL'd (and the UAE webpage also states this),
> >     but there is nothing in the source files that indicate this.  The
> >     files have the copyright statements of individual persons with no
> >     redistribution or licencing info.  I personally am very hesitant
> >     to integrate such code as is.
> 
> Ah yes.  Over the years, there have been many proposals to integrate an
> m68k simulator into the sim source tree only in the past they ended up
> tripping up on the GPL.  Sigh.  Hopefully this one can finally be
> integrated.
> 
> While the copyright doesn't need to be transfered to the FSF the source
> code does need a very clear copyright status.  If someone contributed a
> significant change then that copyright would need to have clearly been
> transfered.
> 
> As a an example PSIM is (C) me.  The contents of one file are (C) IBM.
> The ditribution of that file has been approved - I have bits of paper to
> prove it :-)
> 
>         Andrew
How do we go about and get the pieces of paper to prove that
distribution of that file is approved?

Here is some additional information on the copyrights. I have made a
list of the files in the m68k patch and identified the copyright
listed in each file.  This is the list of UAE authors:

Bernd Schmidt
Herman ten Brugge
Ed Hanway
Samuel Devulder


File					copyright
src/dejagnu/baseboards/m68k-sim.exp	new file
src/gdb/config/m68k/monitor.mt		already in gdb
src/sim/configure			already in gdb
src/sim/configure.in			already in gdb
src/sim/m68k/ChangeLog			new file
src/sim/m68k/Makefile.in		made from gdb's src/sim/sh/Makefile.in
src/sim/m68k/README			new file
src/sim/m68k/build68k.c			Copyright 1995,1996 Bernd Schmidt
src/sim/m68k/compiler.h			(c) 1995 Bernd Schmidt
src/sim/m68k/config.h			Copyright 1995 - 1998 Bernd Schmidt
src/sim/m68k/config.in			made from gdb's src/sim/sh/config.in
src/sim/m68k/configure			made from gdb's src/sim/sh/configure
src/sim/m68k/custom.h			(c) 1995 Bernd Schmidt
src/sim/m68k/fpp.c			Copyright 1996 Herman ten Brugge
src/sim/m68k/gencpu.c			Copyright 1995, 1996, 1997, 1998, 1999, 2000 Bernd Schmidt

src/sim/m68k/include/autoconf.h		(c) 1996 Ed Hanway
src/sim/m68k/include/debug.h		(c) 1995 Bernd Schmidt
src/sim/m68k/include/ersatz.h		(c) 1995 Bernd Schmidt
src/sim/m68k/include/memory.h		Copyright 1995 Bernd Schmidt
src/sim/m68k/include/options.h  	Copyright 1995, 1996 Ed Hanway
					Copyright 1995-98 Bernd Schmidt

src/sim/m68k/include/readcpu.h		none listed (from UAE)
src/sim/m68k/include/sysdeps.h  	Copyright 1996, 1997 Bernd Schmidt
src/sim/m68k/include/uae.h		Copyright 1996 Bernd Schmidt
src/sim/m68k/include/uaeexe.h		(c) 1997 by Samuel Devulder
src/sim/m68k/include/zfile.h		(c) 1996 Samuel Devulder
src/sim/m68k/interp.c			made from gdb's  src/sim/sh/interp.c
src/sim/m68k/machdep/m68k.h		Copyright 1996 Bernd Schmidt
src/sim/m68k/machdep/maccess.h		Copyright 1996 Bernd Schmidt
src/sim/m68k/machdep/rpt.h		Copyright 1997, 1998 Bernd Schmidt
src/sim/m68k/md-fpp.h			Copyright 1996 Herman ten Brugge
src/sim/m68k/memory.c			(c) 1995 Bernd Schmidt
src/sim/m68k/missing.c			Copyright 1997 Bernd Schmidt
src/sim/m68k/newcpu.c			(c) 1995 Bernd Schmidt
src/sim/m68k/newcpu.h			Copyright 1995 Bernd Schmidt
src/sim/m68k/readcpu.c			Copyright 1995,1996 Bernd Schmidt
src/sim/m68k/support.c			Copyright 1996 Bernd Schmidt
src/sim/m68k/sysconfig.h		none listed (from UAE)
src/sim/m68k/table68k			none listed (from UAE)
src/sim/m68k/target.h			Copyright 1997 Bernd Schmidt

-Will

Re: Patch to provide m68k simulator to gdb

[Will Cohen]

Andrew Cagney wrote:
> 
> Below are some quick comment about things that are often missed when
> integrating a new simulator.
> 
> --

This simulator is based on the old sh simulator, so it uses some of the
deprecated features.  I will work on fixing the problems listed below.

-Will

> New simulators use a header file (include/sim-XXX.h - eg
> include/sim-d10v.h) as a way of avoiding magic numbers like:
> 
> sim_fetch_register()
> 
> +     case  0: case  1: case  2: case  3: case  4: case  5: case  6:
> case  7:
> +       /* address regs "a0", "a1", "a2", "a3", "a4", "a5", "fp", "sp"
> */
> +     case  8: case  9: case 10: case 11: case 12: case 13: case 14:
> case 15:
> +       val = saved_state.regs[rn];
> 
> That header along with REGISTER_SIM_REGNO() make it possible to decouple
> the simulators register numbers from GDBs.  Could the code please be
> changed to at least use the header file.
> 
> --
> 
> I have a feeling that this code is implementing a number of
> older/deprecated methods.  Have a look over include/remote-sim.h where
> it clearly identifies deprecated interfaces.  For instance:
> 
> /* Single-step simulator with tracing enabled.
>    THIS PROCEDURE IS DEPRECIATED.
>    THIS PROCEDURE IS EVEN MORE DEPRECATED THAN SIM_SET_TRACE
>    GDB and NRUN do not use this interface.
> 
> Make certain that you use `nrun.c'' and not the older ``run.c''.  Add
> the line:
> 
>   # List of main object files for `run'.
>   SIM_RUN_OBJS = nrun.o
> 
> to your Makefile.in.  It is probably why you implemented sim_trace()
> et.al.
> 
>         Andrew

Re: Patch to provide m68k simulator to gdb

[Andrew Cagney]

> How do we go about and get the pieces of paper to prove that
> distribution of that file is approved?

I don't think that files authored by the below will be a problem.   May
want to let them know of your plans though.

> Here is some additional information on the copyrights. I have made a
> list of the files in the m68k patch and identified the copyright
> listed in each file.  This is the list of UAE authors:
> 
> Bernd Schmidt
> Herman ten Brugge
> Ed Hanway
> Samuel Devulder

The question is what has been contributed and then merged in by the
above.  Remember, if someone contributes a significant change to GDB (I
view sim and gdb as separate entaties), I need to either seek out some
sort of assignment or reject the code.  I would at least check with the
authors that they either have been getting some sort of approval for any
submitted changes or have been avoiding major contributions from authors
beyond the above.

And remember, I'm not a lawyer :-)

	enjoy,
		Andrew

Re: Patch to provide m68k simulator to gdb

[Will Cohen]

There are a number of changes between the old interfaces used by m68k
(and sh) and the newer simulators. Using nrun.c requires a number of
other things to be modified. Is there there some documentation that
describes the various defines and functions required by this newer
interface?  Or is the situation "The code IS the documentation"?  If
"The code IS the documentation," which simulator is the best one to
model the changes after?

I would like to remove these hard-coded numbers in the
sim_fetch_registers and sim_store_register functions. Where should
REGISTER_SIM_REGNO be defined.  I couldn't find an example of its
definition in the version of gdb I am using.

-Will

Andrew Cagney wrote:
> 
> Below are some quick comment about things that are often missed when
> integrating a new simulator.
> 
> --
> 
> New simulators use a header file (include/sim-XXX.h - eg
> include/sim-d10v.h) as a way of avoiding magic numbers like:
> 
> sim_fetch_register()
> 
> +     case  0: case  1: case  2: case  3: case  4: case  5: case  6:
> case  7:
> +       /* address regs "a0", "a1", "a2", "a3", "a4", "a5", "fp", "sp"
> */
> +     case  8: case  9: case 10: case 11: case 12: case 13: case 14:
> case 15:
> +       val = saved_state.regs[rn];
> 
> That header along with REGISTER_SIM_REGNO() make it possible to decouple
> the simulators register numbers from GDBs.  Could the code please be
> changed to at least use the header file.
> 
> --
> 
> I have a feeling that this code is implementing a number of
> older/deprecated methods.  Have a look over include/remote-sim.h where
> it clearly identifies deprecated interfaces.  For instance:
> 
> /* Single-step simulator with tracing enabled.
>    THIS PROCEDURE IS DEPRECIATED.
>    THIS PROCEDURE IS EVEN MORE DEPRECATED THAN SIM_SET_TRACE
>    GDB and NRUN do not use this interface.
> 
> Make certain that you use `nrun.c'' and not the older ``run.c''.  Add
> the line:
> 
>   # List of main object files for `run'.
>   SIM_RUN_OBJS = nrun.o
> 
> to your Makefile.in.  It is probably why you implemented sim_trace()
> et.al.
> 
>         Andrew

Re: Patch to provide m68k simulator to gdb

[Andrew Cagney]

Will Cohen wrote:
> 
> There are a number of changes between the old interfaces used by m68k
> (and sh) and the newer simulators. Using nrun.c requires a number of
> other things to be modified. Is there there some documentation that
> describes the various defines and functions required by this newer
> interface?  Or is the situation "The code IS the documentation"?  If
> "The code IS the documentation," which simulator is the best one to
> model the changes after?
> 
> I would like to remove these hard-coded numbers in the
> sim_fetch_registers and sim_store_register functions. Where should
> REGISTER_SIM_REGNO be defined.  I couldn't find an example of its
> definition in the version of gdb I am using.

Unfortunatly, ``the code IS the documentation''.  The mn10300 may be
best although others probably have better suggestions.

REGISTER_SIM_REGNO would be defined as part of gdb/config/m68k/tm-m68k.h
and friends.  It would map onto a function.  To decide if you need
REGISTER_SIM_REGNO, check the gdb/config/m68k/tm-*.h to see if there is
more than one defintion of REGISTER_BYTE and/or register numbering. 
Hmm, looks like it only appears in tm-m68k.h (correct?).

I would lay out include/sim-m68k.h to match the register numbering
implied by tm-m68k.h:REGISTER_BYTE(REGNUM).  If an m68k target ever
re-orders its registers then that target can implement
REGISTER_SIM_REGNO to map that numbering onto the standard.  Hopefully
no one will do that but if they do the sim side is ready.

	Andrew

Re: Patch to provide m68k simulator to gdb

[Will Cohen]

Bernd Schmit provided me with email addresses for the other three
authors. I sent email to them.  I got response from Herman ten Brugge
and Samuel Devulder. They both said it was okay.  I have not heard back
from Ed Hanway.

-Will

Andrew Cagney wrote:
> 
> > How do we go about and get the pieces of paper to prove that
> > distribution of that file is approved?
> 
> I don't think that files authored by the below will be a problem.   May
> want to let them know of your plans though.
> 
> > Here is some additional information on the copyrights. I have made a
> > list of the files in the m68k patch and identified the copyright
> > listed in each file.  This is the list of UAE authors:
> >
> > Bernd Schmidt
> > Herman ten Brugge
> > Ed Hanway
> > Samuel Devulder
> 
> The question is what has been contributed and then merged in by the
> above.  Remember, if someone contributes a significant change to GDB (I
> view sim and gdb as separate entaties), I need to either seek out some
> sort of assignment or reject the code.  I would at least check with the
> authors that they either have been getting some sort of approval for any
> submitted changes or have been avoiding major contributions from authors
> beyond the above.
> 
> And remember, I'm not a lawyer :-)
> 
>         enjoy,
>                 Andrew

Re: Patch to provide m68k simulator to gdb

[Will Cohen]

I have revised the code to avoid hard coded constants for the register
numbers. The register numbers are defined in sim-main.h.

---

There are a number of depreciated routines in the current
implementation.  These will have to be reworked.  Would it be possible
to check in the m68k simulator into the GDB source tree and then upgrade
the simulator interface to the current implementation?

-Will

Andrew Cagney wrote:
> 
> Below are some quick comment about things that are often missed when
> integrating a new simulator.
> 
> --
> 
> New simulators use a header file (include/sim-XXX.h - eg
> include/sim-d10v.h) as a way of avoiding magic numbers like:
> 
> sim_fetch_register()
> 
> +     case  0: case  1: case  2: case  3: case  4: case  5: case  6:
> case  7:
> +       /* address regs "a0", "a1", "a2", "a3", "a4", "a5", "fp", "sp"
> */
> +     case  8: case  9: case 10: case 11: case 12: case 13: case 14:
> case 15:
> +       val = saved_state.regs[rn];
> 
> That header along with REGISTER_SIM_REGNO() make it possible to decouple
> the simulators register numbers from GDBs.  Could the code please be
> changed to at least use the header file.
> 
> --
> 
> I have a feeling that this code is implementing a number of
> older/deprecated methods.  Have a look over include/remote-sim.h where
> it clearly identifies deprecated interfaces.  For instance:
> 
> /* Single-step simulator with tracing enabled.
>    THIS PROCEDURE IS DEPRECIATED.
>    THIS PROCEDURE IS EVEN MORE DEPRECATED THAN SIM_SET_TRACE
>    GDB and NRUN do not use this interface.
> 
> Make certain that you use `nrun.c'' and not the older ``run.c''.  Add
> the line:
> 
>   # List of main object files for `run'.
>   SIM_RUN_OBJS = nrun.o
> 
> to your Makefile.in.  It is probably why you implemented sim_trace()
> et.al.
> 
>         Andrew

Re: Patch to provide m68k simulator to gdb

[Andrew Cagney]

Will Cohen wrote:
> 
> I have revised the code to avoid hard coded constants for the register
> numbers. The register numbers are defined in sim-main.h.

Just FYI,

If these are the register numbers being passed in via
sim_{fetch,store}_register() then they should be defined
include/sim-m68k.h.

	Andrew

Re: Patch to provide m68k simulator to gdb

[Andrew Cagney]

> There are a number of depreciated routines in the current
> implementation.  These will have to be reworked.  Would it be possible
> to check in the m68k simulator into the GDB source tree and then upgrade
> the simulator interface to the current implementation?

I'm sorry, but no.

In the past I've suggested that code like this be parked on a branch
while the problems are resolved (no one has actually taken me up on this
though).  The include/remote-sim.h interface isn't likely to change soon
so such a move is pretty safe.

Anyway, before doing even this, things would still need to be ok on the
licencing side.

	Andrew

Re: Patch to provide m68k simulator to gdb

[Will Cohen]

Andrew Cagney wrote:
> 
> Will Cohen wrote:
> >
> > I have revised the code to avoid hard coded constants for the register
> > numbers. The register numbers are defined in sim-main.h.
> 
> Just FYI,
> 
> If these are the register numbers being passed in via
> sim_{fetch,store}_register() then they should be defined
> include/sim-m68k.h.
> 
>         Andrew

If that's the way to do it okay.  I only saw include/sim-d10v.h there.
None of the other simulators followed this approach. I was emulating
what I saw in the vast majority of the simulators.

-Will

Re: Patch to provide m68k simulator to gdb

[Frank Ch. Eigler]

Will Cohen <wcohen@redhat.com> writes:

: [...]
: > If these are the register numbers being passed in via
: > sim_{fetch,store}_register() then they should be defined
: > include/sim-m68k.h.
: 
: If that's the way to do it okay.  I only saw include/sim-d10v.h there.
: None of the other simulators followed this approach. I was emulating
: what I saw in the vast majority of the simulators.

FWIW, I agree with Will.  The sim-d10v.h, while not a bad idea, is a
very lonely and rather old precedent to become required of new ports.


- FChE

Re: Patch to provide m68k simulator to gdb

[Frank Ch. Eigler]

Andrew Cagney <ac131313@cygnus.com> writes:

: > There are a number of depreciated routines in the current
: > implementation.  These will have to be reworked.  Would it be possible
: > to check in the m68k simulator into the GDB source tree and then upgrade
: > the simulator interface to the current implementation?
: 
: I'm sorry, but no.

FWIW, I disagree.  If the code is functional, and the contributor is
willing to commit to cleaning up rough edges over the short-term
future, it should be allowed to go in.

: In the past I've suggested that code like this be parked on a branch
: while the problems are resolved (no one has actually taken me up on this
: though).  [...]

I'm not too surprised -- being parked on a separate branch is perhaps
a bit like being placed into a penalty box (if you pardon the hockey
analogy).

: Anyway, before doing even this, things would still need to be ok on the
: licencing side.

That's right though.


- FChE

Re: Patch to provide m68k simulator to gdb

[Andrew Cagney]

"Frank Ch. Eigler" wrote:
> 
> Will Cohen <wcohen@redhat.com> writes:
> 
> : [...]
> : > If these are the register numbers being passed in via
> : > sim_{fetch,store}_register() then they should be defined
> : > include/sim-m68k.h.
> :
> : If that's the way to do it okay.  I only saw include/sim-d10v.h there.
> : None of the other simulators followed this approach. I was emulating
> : what I saw in the vast majority of the simulators.
> 
> FWIW, I agree with Will.  The sim-d10v.h, while not a bad idea, is a
> very lonely and rather old precedent to become required of new ports.

FYI, That file was only introduced a year ago.  It occured when the d10v
was given an upgrade.  I've been pretty consistent in asking anyone with
a new simulator (merged or not) to follow that convention.

	Andrew