Add support for RedBoot SWIs to ARM Simulator

Add support for RedBoot SWIs to ARM Simulator

[Nick Clifton]

Hi Guys,

  I am applying the patch below to add support for the SWI used by
  RedBoot to implement some of its system calls.  The patch only
  supports those system calls already supported by the simulator's
  Angel and Demon SWI protocol support.

  Note - it is not possible to support the RedBoot SWI in Thumb mode,
  since this SWI value - 0x18 - is also the thumb breakpoint value
  used by GDB.

Cheers
        Nick

2002-05-09  Nick Clifton  <nickc@cambridge.redhat.com>

	* armos.c (ARMul_OSHandleSWI): Support the RedBoot SWI in ARM
	mode and some of its system calls.

Index: sim/arm/armos.c
===================================================================
RCS file: /cvs/src/src/sim/arm/armos.c,v
retrieving revision 1.11
diff -c -3 -p -w -r1.11 armos.c
*** sim/arm/armos.c	21 Feb 2002 20:22:49 -0000	1.11
--- sim/arm/armos.c	9 May 2002 10:01:16 -0000
*************** ARMul_OSHandleSWI (ARMul_State * state, 
*** 635,640 ****
--- 635,703 ----
        /* These are used by the FPE code.  */
        break;
        
+     case 0x180001: /* RedBoot's Syscall SWI in ARM mode.  */
+       switch (state->Reg[0])
+ 	{
+ 	  /* These numbers are defined in libgloss/syscall.h
+ 	     but the simulator should not be dependend upon
+ 	     libgloss being installed.  */
+ 	case 1:  /* Exit.  */
+ 	  state->Emulate = FALSE;
+ 	  return TRUE;
+ 
+ 	case 2:  /* Open.  */
+ 	  SWIopen (state, state->Reg[1], state->Reg[2]);
+ 	  return TRUE;
+ 
+ 	case 3:  /* Close.  */
+ 	  state->Reg[0] = close (state->Reg[1]);
+ 	  OSptr->ErrorNo = errno;
+ 	  return TRUE;
+ 
+ 	case 4:  /* Read.  */
+ 	  SWIread (state, state->Reg[1], state->Reg[2], state->Reg[3]);
+ 	  return TRUE;
+ 
+ 	case 5:  /* Write.  */
+ 	  SWIwrite (state, state->Reg[1], state->Reg[2], state->Reg[3]);
+ 	  return TRUE;
+ 
+ 	case 6:  /* Lseek.  */
+ 	  state->Reg[0] = lseek (state->Reg[1], state->Reg[2], state->Reg[3]);
+ 	  OSptr->ErrorNo = errno;
+ 	  return TRUE;
+ 
+ 	case 17: /* Utime.  */
+ 	  state->Reg[0] = (ARMword) time (state->Reg[1]);
+ 	  OSptr->ErrorNo = errno;
+ 	  return (TRUE);
+ 
+ 	case 7:  /* Unlink.  */
+ 	case 8:  /* Getpid.  */
+ 	case 9:  /* Kill.  */
+ 	case 10: /* Fstat.  */
+ 	case 11: /* Sbrk.  */
+ 	case 12: /* Argvlen.  */
+ 	case 13: /* Argv.  */
+ 	case 14: /* ChDir.  */
+ 	case 15: /* Stat.  */
+ 	case 16: /* Chmod.  */
+ 	case 18: /* Time.  */
+ 	  sim_callback->printf_filtered
+ 	    (sim_callback,
+ 	     "sim: unhandled RedBoot syscall '%d' encountered - ignoring\n",
+ 	     state->Reg[0]);
+ 	  return FALSE;
+ 
+ 	default:
+ 	  sim_callback->printf_filtered
+ 	    (sim_callback,
+ 	     "sim: unknown RedBoot syscall '%d' encountered - ignoring\n",
+ 	     state->Reg[0]);
+ 	  return FALSE;
+ 	}
+       return TRUE;
+       
      default:
        /* If there is a SWI vector installed use it.  */
        if (state->is_XScale && saved_number != -1)

Re: Add support for RedBoot SWIs to ARM Simulator

[Richard Earnshaw]

Hi Guys,

  I am applying the patch below to add support for the SWI used by
  RedBoot to implement some of its system calls.  The patch only
  supports those system calls already supported by the simulator's
  Angel and Demon SWI protocol support.

  Note - it is not possible to support the RedBoot SWI in Thumb mode,
  since this SWI value - 0x18 - is also the thumb breakpoint value
  used by GDB.


This may trample on the toes of somebody using that SWI as a real trap 
into an OS.  We probably should have a way of configuring the simulator at 
run-time to allow emulation of a set of SWI values.  Either from a 
command-line switch (for the arm-...-run command) or a gdb hook (for use 
within gdb).


Something like:

	arm-elf-run -emul-swi={redboot|angel|demon|none}

R.

Re: Add support for RedBoot SWIs to ARM Simulator

[Nick Clifton]

Hi Richard,

> This may trample on the toes of somebody using that SWI as a real
> trap into an OS.

Well it would if they were then trying to run code compiled for that
OS on the simulator.

> We probably should have a way of configuring the simulator at 
> run-time to allow emulation of a set of SWI values.  Either from a  
> command-line switch (for the arm-...-run command) or a gdb hook (for use 
> within gdb).

> Something like:
> 
> 	arm-elf-run -emul-swi={redboot|angel|demon|none}

Hmm, well that could be done.  Personally I would hold off doing it
until there is actually a situation where it is needed.  At the moment
support all three SWI interfaces simultaneously is not a problem.  So
unless someone comes up with a real situation where it causes problems
I would leave things as they are.  (Just my 2 cents worth).

Cheers
        Nick

Re: Add support for RedBoot SWIs to ARM Simulator

[Richard Earnshaw]

> Hi Richard,
> 
> > This may trample on the toes of somebody using that SWI as a real
> > trap into an OS.
> 
> Well it would if they were then trying to run code compiled for that
> OS on the simulator.
> 
> > We probably should have a way of configuring the simulator at 
> > run-time to allow emulation of a set of SWI values.  Either from a  
> > command-line switch (for the arm-...-run command) or a gdb hook (for use 
> > within gdb).
> 
> > Something like:
> > 
> > 	arm-elf-run -emul-swi={redboot|angel|demon|none}
> 
> Hmm, well that could be done.  Personally I would hold off doing it
> until there is actually a situation where it is needed.  At the moment
> support all three SWI interfaces simultaneously is not a problem.  So
> unless someone comes up with a real situation where it causes problems
> I would leave things as they are.  (Just my 2 cents worth).
> 
> Cheers
>         Nick
> 


Actually, we already have.   Look at the mess that is involved with 
testing for XScale -- saying that XScale doesn't support Demon swi's is 
nonsence -- especially when we default to enabling XScale extensions for 
some simulations.  I ran into something like this only the other day -- 
the simulator was turning on XScale (despite the fact that I wasn't using 
any of those extensions), and thus disabling the SWIs I wanted.

Note the comment at the top of ARMul_OSHandleSWI which really gives the 
game away:

  /* Intel do not want DEMON SWI support.  */
  if (state->is_XScale)
	...

R.

Add support for target switches in simulator

[Nick Clifton]

Hi Guys,

  I would like permission to apply the following patch.  It adds the
  ability for simulator backends to parse their own command line
  switches, thus creating target specific simulator options.

  I would like this facility in order to be able to add a new switch
  to the ARM simulator - a switch to select which set(s) of SWI
  emulations it should perform.

  I have not worked out how this feature would be accessed from GDB.
  My guess is that the switches could be added to the arguments passed
  via sim_open(), but how would a GDB user tell GDB to add these
  switches ?

Cheers
        Nick

sim/common/ChangeLog
2002-05-16  Nick Clifton  <nickc@cambridge.redhat.com>

	* run.c (main): Call sim_target_parse_command_line if
	SIM_TARGET_SWITCHES is defined.
	(usage): Call sim_target_display_usage if SIM_TARGET_SWITCHES
	is defined.

include/ChangeLog
2002-05-16  Nick Clifton  <nickc@cambridge.redhat.com>

	* remote-sim.h: Provide prototypes for
	sim_target_parse_command_line and sim_target_display_usage
	if SIM_TARGET_SWITCHES is defined.

Index: sim/common/run.c
===================================================================
RCS file: /cvs/src/src/sim/common/run.c,v
retrieving revision 1.7
diff -c -3 -p -w -r1.7 run.c
*** sim/common/run.c	21 Dec 2001 00:47:18 -0000	1.7
--- sim/common/run.c	16 May 2002 16:04:36 -0000
*************** main (ac, av)
*** 111,116 ****
--- 111,120 ----
    default_callback.init (&default_callback);
    sim_set_callbacks (&default_callback);
  
+ #ifdef SIM_TARGET_SWITCHES
+   ac = sim_target_parse_command_line (ac, av);
+ #endif
+ 
    /* FIXME: This is currently being rewritten to have each simulator
       do all argv processing.  */
  
*************** usage ()
*** 334,338 ****
--- 338,346 ----
    fprintf (stderr, "\n");
    fprintf (stderr, "program args    Arguments to pass to simulated program.\n");
    fprintf (stderr, "                Note: Very few simulators support this.\n");
+ #ifdef SIM_TARGET_SWITCHES
+   fprintf (stderr, "\nTarget specific options:\n");
+   sim_target_display_usage ();
+ #endif
    exit (1);
  }

Index: include/remote-sim.h
===================================================================
RCS file: /cvs/src/src/include/remote-sim.h,v
retrieving revision 1.4
diff -c -3 -p -w -r1.4 remote-sim.h
*** include/remote-sim.h	14 Mar 2001 02:27:43 -0000	1.4
--- include/remote-sim.h	16 May 2002 16:07:49 -0000
*************** void sim_set_profile_size PARAMS ((int n
*** 346,351 ****
--- 346,362 ----
     multi-cpu simulators. */
  
  void sim_kill PARAMS ((SIM_DESC sd));
+ 
+ #ifdef SIM_TARGET_SWITCHES
+   /* Parse the command line, extracting any target specific switches
+      before the generic simulator code gets a chance to complain
+      about them.  Returns the adjusted value of argc.  */
+ int sim_target_parse_command_line PARAMS ((int, char **));
+ 
+   /* Display a list of target specific switches supported by this
+      target.  */
+ void sim_target_display_usage PARAMS ((void));
+ #endif
  
  #ifdef __cplusplus
  }

Re: Add support for target switches in simulator

[Richard Earnshaw]

nickc@cambridge.redhat.com said:
> 
>   I would like permission to apply the following patch.  It adds the
>   ability for simulator backends to parse their own command line
>   switches, thus creating target specific simulator options.
>
>   I would like this facility in order to be able to add a new switch
>   to the ARM simulator - a switch to select which set(s) of SWI
>   emulations it should perform.
>
>   I have not worked out how this feature would be accessed from GDB.
>   My guess is that the switches could be added to the arguments passed
>   via sim_open(), but how would a GDB user tell GDB to add these
>   switches ? 

Hmm, I thought there was already a way to tell the simulator what amount 
of memory to use.  Couldn't a similar method be employed.

R.

PS.  I haven't looked at how that was done, but I recall a discussion 
about this recently on the mailing list related to increasing the amount 
of memory for a Java testsuite run.

Re: Add support for target switches in simulator

[Nick Clifton]

Hi Guys,

Answers to comments on my patch submission:

> >  I would like permission to apply the following patch.  It adds
> >  the ability for simulator backends to parse their own command
> >  line switches, thus creating target specific simulator options.

> Frank Ch. Eigler writes:
> 
> How does this proposed facility compare to that provided by
> sim/common/sim-options*?

It is a similar kind of thing accept that it has two advantages:

  * It works for simulators that do not use sim-common.[ch]  (such as
    the ARM simualtor).

  * It isolates all of the target specific code in the target specific
    subdirectories, and just has a very small intrusion into the
    generic code.  (Unlike say the SIM_H8300 option).



> >  I have not worked out how this feature would be accessed from
> >  GDB.  My guess is that the switches could be added to the
> >  arguments passed via sim_open(), but how would a GDB user tell
> >  GDB to add these switches ?

> Richard Earnshaw <rearnsha@arm.com> writes:

> Hmm, I thought there was already a way to tell the simulator what
> amount of memory to use.

So did I, but looking through the GDB sources I do not see a place
where it is used.

> Couldn't a similar method be employed.

That method is specific to setting the memory size - it uses a
simulator/debugger interface call specifically set up for the
purpose.  I looked for the function - sim_size() - and found it being
used by the run program but not by GDB.  I am puzzled.

Anyway the point here is that setting the memory size appears to be a
specific API function and I want a generic method to set any kind of
target specific option.


> From: Michael Snyder <msnyder@redhat.com>

From memory, don't you do something like:

	(gdb) target sim xxx=yyy

Yup that works - thanks Michael.

I have now updated my ARM SIM patch so that it will work using this
interface.  So if the common sim part can be approved then we will
have a complete method for controlling SWI emulation in the ARM
simulator.

Cheers
        Nick

PS.  I will post the arm sim parts of the patch to this list shortly.

Re: Add support for target switches in simulator

[Richard Earnshaw]

> > How does this proposed facility compare to that provided by
> > sim/common/sim-options*?
> 
> It is a similar kind of thing accept that it has two advantages:
> 
>   * It works for simulators that do not use sim-common.[ch]  (such as
>     the ARM simualtor).

Is there a good reason why the ARM simulator is not using sim-common?

R.

Re: Add support for target switches in simulator

[Nick Clifton]

Hi Richard,

> > > How does this proposed facility compare to that provided by
> > > sim/common/sim-options*?
> > 
> > It is a similar kind of thing accept that it has two advantages:
> > 
> >   * It works for simulators that do not use sim-common.[ch]  (such as
> >     the ARM simualtor).
> 
> Is there a good reason why the ARM simulator is not using sim-common?

I doubt it.  I suspect that it is just a historical thing.

Cheers
        Nick

Re: Add support for target switches in simulator

[Andrew Cagney]

> Hi Richard,
> 
> 
>> > > How does this proposed facility compare to that provided by
>> > > sim/common/sim-options*?
> 
>> > 
>> > It is a similar kind of thing accept that it has two advantages:
>> > 
>> >   * It works for simulators that do not use sim-common.[ch]  (such as
>> >     the ARM simualtor).
> 
>> 
>> Is there a good reason why the ARM simulator is not using sim-common?
> 
> 
> I doubt it.  I suspect that it is just a historical thing.

It is non-trivial.  Sim-common is somewhat monolythic (all or nothing) 
and that makes it less than easy to use just some parts of the framework.

In hindsight (hey I'm part responsible :-) I think it should have been 
less macro centric and more cleanly modula(1).  That way it would be 
easier to integrate existing simulators - have them use just the parts 
they need.

I've filed change-requests suggesting this.

enjoy,
Andrew

(1) I learnt two lessons, avoid `typedef struct' and avoid `macros' :-)

Re: Add support for target switches in simulator

[Frank Ch. Eigler]

nickc wrote:

> [...]
> > How does this proposed facility compare to that provided by
> > sim/common/sim-options*?
> 
> It is a similar kind of thing accept that it has two advantages:


>   * It works for simulators that do not use sim-common.[ch]  (such as
>     the ARM simualtor).

I don't understand.  There is no sim-common.[ch] file, and the new
module you are proposing is to go under sim/common.  It's as if you
want to add a new, alternative option handling module under
sim/common.  Can you describe what difficulties you encountered, when
trying to use the sim-options code as is (assuming you tried)?


>   * It isolates all of the target specific code in the target specific
>     subdirectories, and just has a very small intrusion into the
>     generic code.  (Unlike say the SIM_H8300 option).

The sim-options code can do this already, when used correctly.
Look at calls to sim_add_option_table in d30v, fr30, mips. m32r,
m68hc11, mn10300, ... :-)


- FChE

Re: Add support for target switches in simulator

[Andrew Cagney]

> I have not worked out how this feature would be accessed from
>> >  GDB.  My guess is that the switches could be added to the
>> >  arguments passed via sim_open(), but how would a GDB user tell
>> >  GDB to add these switches ?
> 
> 
>> Richard Earnshaw <rearnsha@arm.com> writes:
> 
> 
>> Hmm, I thought there was already a way to tell the simulator what
>> amount of memory to use.

I've an approved patch for:

(gdb) target sim -m <number>

Nick suggested some tweaks that I didn't get back to :-/

> So did I, but looking through the GDB sources I do not see a place
> where it is used.

It isn't.  The interface is marked obsolete.  Instead sim-common 
simulators use:

(gdb) sim memory-size ...

>> Couldn't a similar method be employed.
> 
> 
> That method is specific to setting the memory size - it uses a
> simulator/debugger interface call specifically set up for the
> purpose.  I looked for the function - sim_size() - and found it being
> used by the run program but not by GDB.  I am puzzled.
> 
> Anyway the point here is that setting the memory size appears to be a
> specific API function and I want a generic method to set any kind of
> target specific option.

Andrew

Re: Add support for target switches in simulator

[Frank Ch. Eigler]

nickc wrote:

> [..]
>   I would like permission to apply the following patch.  It adds the
>   ability for simulator backends to parse their own command line
>   switches, thus creating target specific simulator options.
> [...]

How does this proposed facility compare to that provided by
sim/common/sim-options*?


- FChE

Re: Add support for target switches in simulator

[Michael Snyder]

Nick Clifton wrote:
> 
> Hi Guys,
> 
>   I would like permission to apply the following patch.  It adds the
>   ability for simulator backends to parse their own command line
>   switches, thus creating target specific simulator options.
> 
>   I would like this facility in order to be able to add a new switch
>   to the ARM simulator - a switch to select which set(s) of SWI
>   emulations it should perform.
> 
>   I have not worked out how this feature would be accessed from GDB.
>   My guess is that the switches could be added to the arguments passed
>   via sim_open(), but how would a GDB user tell GDB to add these
>   switches ?

From memory, don't you do something like:

	(gdb) target sim xxx=yyy


> 
> Cheers
>         Nick
> 
> sim/common/ChangeLog
> 2002-05-16  Nick Clifton  <nickc@cambridge.redhat.com>
> 
>         * run.c (main): Call sim_target_parse_command_line if
>         SIM_TARGET_SWITCHES is defined.
>         (usage): Call sim_target_display_usage if SIM_TARGET_SWITCHES
>         is defined.
> 
> include/ChangeLog
> 2002-05-16  Nick Clifton  <nickc@cambridge.redhat.com>
> 
>         * remote-sim.h: Provide prototypes for
>         sim_target_parse_command_line and sim_target_display_usage
>         if SIM_TARGET_SWITCHES is defined.
> 
> Index: sim/common/run.c
> ===================================================================
> RCS file: /cvs/src/src/sim/common/run.c,v
> retrieving revision 1.7
> diff -c -3 -p -w -r1.7 run.c
> *** sim/common/run.c    21 Dec 2001 00:47:18 -0000      1.7
> --- sim/common/run.c    16 May 2002 16:04:36 -0000
> *************** main (ac, av)
> *** 111,116 ****
> --- 111,120 ----
>     default_callback.init (&default_callback);
>     sim_set_callbacks (&default_callback);
> 
> + #ifdef SIM_TARGET_SWITCHES
> +   ac = sim_target_parse_command_line (ac, av);
> + #endif
> +
>     /* FIXME: This is currently being rewritten to have each simulator
>        do all argv processing.  */
> 
> *************** usage ()
> *** 334,338 ****
> --- 338,346 ----
>     fprintf (stderr, "\n");
>     fprintf (stderr, "program args    Arguments to pass to simulated program.\n");
>     fprintf (stderr, "                Note: Very few simulators support this.\n");
> + #ifdef SIM_TARGET_SWITCHES
> +   fprintf (stderr, "\nTarget specific options:\n");
> +   sim_target_display_usage ();
> + #endif
>     exit (1);
>   }
> 
> Index: include/remote-sim.h
> ===================================================================
> RCS file: /cvs/src/src/include/remote-sim.h,v
> retrieving revision 1.4
> diff -c -3 -p -w -r1.4 remote-sim.h
> *** include/remote-sim.h        14 Mar 2001 02:27:43 -0000      1.4
> --- include/remote-sim.h        16 May 2002 16:07:49 -0000
> *************** void sim_set_profile_size PARAMS ((int n
> *** 346,351 ****
> --- 346,362 ----
>      multi-cpu simulators. */
> 
>   void sim_kill PARAMS ((SIM_DESC sd));
> +
> + #ifdef SIM_TARGET_SWITCHES
> +   /* Parse the command line, extracting any target specific switches
> +      before the generic simulator code gets a chance to complain
> +      about them.  Returns the adjusted value of argc.  */
> + int sim_target_parse_command_line PARAMS ((int, char **));
> +
> +   /* Display a list of target specific switches supported by this
> +      target.  */
> + void sim_target_display_usage PARAMS ((void));
> + #endif
> 
>   #ifdef __cplusplus
>   }

Re: Add support for target switches in simulator

[Andrew Cagney]

> Index: include/remote-sim.h
> ===================================================================
> RCS file: /cvs/src/src/include/remote-sim.h,v
> retrieving revision 1.4
> diff -c -3 -p -w -r1.4 remote-sim.h
> *** include/remote-sim.h	14 Mar 2001 02:27:43 -0000	1.4
> --- include/remote-sim.h	16 May 2002 16:07:49 -0000
> *************** void sim_set_profile_size PARAMS ((int n
> *** 346,351 ****
> --- 346,362 ----
>      multi-cpu simulators. */
>   
>   void sim_kill PARAMS ((SIM_DESC sd));
> + 
> + #ifdef SIM_TARGET_SWITCHES
> +   /* Parse the command line, extracting any target specific switches
> +      before the generic simulator code gets a chance to complain
> +      about them.  Returns the adjusted value of argc.  */
> + int sim_target_parse_command_line PARAMS ((int, char **));
> + 
> +   /* Display a list of target specific switches supported by this
> +      target.  */
> + void sim_target_display_usage PARAMS ((void));
> + #endif
>   
>   #ifdef __cplusplus
>   }

Nick,

I can understand you adding the interface here (that is where all the 
others are).  However, see:
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb

(in hindsight, the functions should be just moved and not renamed, and 
I'm not asking you to do any of that).

I think a better place would be a new file sim/common/sim-run.h to 
indicate that this is part of the interface that run.c uses.

As for converting Arm to use the new framework, I would recommend 
creating a change-request :-)

Andrew

Re: Add support for target switches in simulator

[Nick Clifton]

HI Guys,

> Andrew Cagney <ac131313@cygnus.com> writes:

> I think a better place would be a new file sim/common/sim-run.h to 
> indicate that this is part of the interface that run.c uses.

OK - an adjusted patch is attached below.

> As for converting Arm to use the new framework, I would recommend 
> creating a change-request :-)

I think that would be best.  I certainly feel that it is outside the
scope of this patch, so I hope that continuing to use the old
interface (ie not sim-options.[ch]) will not stop the patch from being
accepted.

  Is this version OK ?

Cheers
        Nick


2002-05-20  Nick Clifton  <nickc@cambridge.redhat.com>

	* run.h: New header.  Provide prototypes for functions used
	between run() and libsim.a which are not used by GDB.
	* run.c: Include run.h.
        (main): If SIM_TARGET_SWITCHES is defined call
        sim_target_parse_command_line.
        (usage): If SIM_TARGET_SWITCHES is defined call
        sim_target_display_usage.

Index: sim/common/run.c
===================================================================
RCS file: /cvs/src/src/sim/common/run.c,v
retrieving revision 1.8
diff -c -3 -p -w -r1.8 run.c
*** sim/common/run.c	17 May 2002 19:09:12 -0000	1.8
--- sim/common/run.c	20 May 2002 13:06:02 -0000
*************** with this program; if not, write to the 
*** 46,51 ****
--- 46,52 ----
  #include "callback.h"
  #include "remote-sim.h"
  #include "ansidecl.h"
+ #include "run.h"
  
  static void usage PARAMS ((void));
  extern int optind;
*************** main (ac, av)
*** 111,116 ****
--- 112,121 ----
    default_callback.init (&default_callback);
    sim_set_callbacks (&default_callback);
  
+ #ifdef SIM_TARGET_SWITCHES
+   ac = sim_target_parse_command_line (ac, av);
+ #endif
+ 
    /* FIXME: This is currently being rewritten to have each simulator
       do all argv processing.  */
  
*************** usage ()
*** 338,342 ****
--- 343,351 ----
    fprintf (stderr, "\n");
    fprintf (stderr, "program args    Arguments to pass to simulated program.\n");
    fprintf (stderr, "                Note: Very few simulators support this.\n");
+ #ifdef SIM_TARGET_SWITCHES
+   fprintf (stderr, "\nTarget specific options:\n");
+   sim_target_display_usage ();
+ #endif
    exit (1);
  }

*** /dev/null	Thu Aug 30 21:30:55 2001
--- sim/common/run.h	Mon May 20 14:03:14 2002
***************
*** 0 ****
--- 1,32 ----
+ /* This file defines the part of the interface between the standalone
+    simaulator program - run - and simulator library - libsim.a - that
+    is not used by GDB.  The GDB part is described in include/remote-sim.h.
+    
+    Copyright 2002 Free Software Foundation, Inc.
+ 
+    This file is part of GDB.
+ 
+    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
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+ 
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+ 
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+ 
+ #ifdef SIM_TARGET_SWITCHES
+   /* Parse the command line, extracting any target specific switches
+      before the generic simulator code gets a chance to complain
+      about them.  Returns the adjusted value of argc.  */
+ int sim_target_parse_command_line PARAMS ((int, char **));
+ 
+   /* Display a list of target specific switches supported by this
+      target.  */
+ void sim_target_display_usage PARAMS ((void));
+ #endif

Re: Add support for target switches in simulator

[Andrew Cagney]

> HI Guys,
> 
> 
>> Andrew Cagney <ac131313@cygnus.com> writes:
> 
> 
>> I think a better place would be a new file sim/common/sim-run.h to 
>> indicate that this is part of the interface that run.c uses.
> 
> 
> OK - an adjusted patch is attached below.

Doh! Doh!

I should have said run-sim.h to match remote-sim.h. You've got run.h :-)

>> As for converting Arm to use the new framework, I would recommend 
>> creating a change-request :-)
> 
> 
> I think that would be best.  I certainly feel that it is outside the
> scope of this patch, so I hope that continuing to use the old
> interface (ie not sim-options.[ch]) will not stop the patch from being
> accepted.

Yep.

>   Is this version OK ?

Yep, I'm happy with above.

Andrew

Re: Add support for target switches in simulator

[Richard Earnshaw]

> HI Guys,
> 
> > Andrew Cagney <ac131313@cygnus.com> writes:
> 
> > I think a better place would be a new file sim/common/sim-run.h to 
> > indicate that this is part of the interface that run.c uses.
> 
> OK - an adjusted patch is attached below.
> 
> > As for converting Arm to use the new framework, I would recommend 
> > creating a change-request :-)
> 
> I think that would be best.  I certainly feel that it is outside the
> scope of this patch, so I hope that continuing to use the old
> interface (ie not sim-options.[ch]) will not stop the patch from being
> accepted.

I've no objection, provided there would be no user-visible changes if we 
migrated to the standard framework once the PR was addressed.

R.

Re: Add support for target switches in simulator

[Nick Clifton]

Hi Richard,

> I've no objection, provided there would be no user-visible changes
> if we migrated to the standard framework once the PR was addressed.

I do not believe that there will be.  The standard framework has
support for target specific switches, so there is no reason to suppose
that maintaining this feature would be a problem.

Cheers
        Nick

Re: Add support for RedBoot SWIs to ARM Simulator

[Frank Ch. Eigler]

nickc wrote:

> [...]
> > We probably should have a way of configuring the simulator at 
> > run-time to allow emulation of a set of SWI values.  [...]
> > 	arm-elf-run -emul-swi={redboot|angel|demon|none}
> 
> Hmm, well that could be done.  Personally I would hold off doing it
> until there is actually a situation where it is needed.  [...]

If one ever wants to run an OS on the simulator, then it must be able
to *not* intercept any SWIs, since the OS would itself take care of
the calls.  In sid, we have a separate general configuration option
for this kind of thing.


- FChE