is sim/common documented anywhere?

is sim/common documented anywhere?

[DJ Delorie]

I'm trying to do "the right thing" wrt using sim/common, but so far
all I can find is a spaghetti mess of configury, scattered includes,
and sample uses (i.e. other simulators, which themselves are poorly
documentated, if at all), with no clear documentation on how to use
any of it.

Re: is sim/common documented anywhere?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 628 bytes --]

On Wednesday 22 August 2012 18:58:05 DJ Delorie wrote:
> I'm trying to do "the right thing" wrt using sim/common, but so far
> all I can find is a spaghetti mess of configury, scattered includes,
> and sample uses (i.e. other simulators, which themselves are poorly
> documentated, if at all), with no clear documentation on how to use
> any of it.

sim/README-HACKING and the comments in the files themselves (.h and .c) are the 
only documentation i know of.  many of the sim/common/ files have half-decent 
api/utility type comments in them.

if you have a question, i'd be happy to answer if i knew it :)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: is sim/common documented anywhere?

[DJ Delorie]

I've read through the comments and README.  Mostly what's missing is
some guide to help tell people where to begin, what parts to worry
about, and WHY you'd use any given piece.

Example: how do I set up the chip's RAM/ROM regions?  Do I want them
to be user-configurable?  If so, what's the best way to manage them?
I could look at the other simulators and see what functions they call,
then muddle through the comments to try to figure out something
appropriate to pass them, but none of that means I know what I'm doing
or why I'm doing it.

Re: is sim/common documented anywhere?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1947 bytes --]

On Wednesday 22 August 2012 19:41:42 DJ Delorie wrote:
> I've read through the comments and README.  Mostly what's missing is
> some guide to help tell people where to begin, what parts to worry
> about, and WHY you'd use any given piece.

yes, some of the fundamental pieces explaining how it all comes together is 
missing

> Example: how do I set up the chip's RAM/ROM regions? 

you use sim_core_attach to attach memory regions.  the mapmask allows you to 
set different permissions on it.  be aware that the sim currently has an issue 
when used in conjunction with gdb -- the read/write bits not only lock out the 
simulated code from accessing the region, but gdb too :(.

so you can't setup something like executable-only memory by specifying 
access_exec as then when you try to use `x` or `dis` from gdb, you'd get back 
an error -- the memory may not be read.  similarly, if you were to try to use 
`load` to load an executable with custom contents into that region you'd again 
get denied -- gdb is not allowed to write to it.

i mentioned this a while ago seeking ideas, but didn't get any response.

> Do I want them to be user-configurable?

yes.  the idea of the sim is two fold: provide simulation of the ISA with no 
SoC related details (peripherals/memory regions/etc...), and then t optionally 
provide support for common SoCs.

> If so, what's the best way to manage them?

check out sim-model.c.  this lets you specify --model on the command line to 
select different SoCs.  this sets up CPU_MODEL (cpu) which you can then parse 
in the early init phases of the sim (sim_open) to attach an appropriate set of 
memory regions based on the model.

you can also use SIM_AC_OPTION_DEFAULT_MODEL() in your configure.ac to select 
the default model for the sim if you want one.

if you have different ISAs to select between, you probably want to use --
architecture for that.

HTH
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: is sim/common documented anywhere?

[DJ Delorie]

Ok, how do I get past this one...

sim-events.c:1076: assertion failed - events->nr_ticks_to_process != 0

This happens after sim_create_inferior is called, but before
sim_engine_run is called.

Re: is sim/common documented anywhere?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 910 bytes --]

On Friday 24 August 2012 16:03:51 DJ Delorie wrote:
> Ok, how do I get past this one...
> 
> sim-events.c:1076: assertion failed - events->nr_ticks_to_process != 0
> 
> This happens after sim_create_inferior is called, but before
> sim_engine_run is called.

ah, sometimes i think that error is the bane of my [sim] existence.  
annoyingly, it can arise for a few different reasons.

first, you don't want the common/sim-run.c [1].  although i'll probably just 
gut that already and make it usable since no one ever got back to me and make 
it so it is usable by default ...

second, you're using nrun.c right ?  make sure SIM_RUN_OBJS=nrun.o in your 
Makefile.in.

third, how are you launching ?  `gdb` or `run` ?

fourth, i vaguely recall not fulling initializing the state in the arch 
sim_open() can cause this to trip.
-mike

1: http://sourceware.org/ml/gdb/2010-02/msg00046.html

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: is sim/common documented anywhere?

[DJ Delorie]

Yes, I'm using nrun.o

Problem turned out to be this: running "make all-sim" doesn't return
an error if your compilation fails, at least on my system.  Once I
fixed all the bugs and got a NEW "run" binary, all that initialization
I had been adding "suddenly" happened ;-)

I've now gotten to the point where sim_engine_run() is called.  I
assume this is where I put the actual core simulation?

Re: is sim/common documented anywhere?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1087 bytes --]

On Friday 24 August 2012 20:49:36 DJ Delorie wrote:
> Problem turned out to be this: running "make all-sim" doesn't return
> an error if your compilation fails, at least on my system.

weird ... it does for me.  i don't think the rules added by the common make 
fragments swallow any errors ...

> I've now gotten to the point where sim_engine_run() is called.  I
> assume this is where I put the actual core simulation?

yes & no.  i think the core of the sim_engine_run loop is best left simple:

void
sim_engine_run (SIM_DESC sd,
                int next_cpu_nr, /* ignore  */
                int nr_cpus, /* ignore  */  
                int siggnal) /* ignore  */
{
  SIM_CPU *cpu;

  SIM_ASSERT (STATE_MAGIC (sd) == SIM_MAGIC_NUMBER);

  cpu = STATE_CPU (sd, 0);

  while (1)
    {
      step_once (cpu);
      if (sim_events_tick (sd))
        sim_events_process (sd);
    }
}

feel free to call "step_once" whatever you want -- there doesn't appear to be 
consistency atm.  but that func is where you'd put all the decode+execute 
logic.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]