Training courses

Kernel and Embedded Linux

Bootlin training courses

Embedded Linux, kernel,
Yocto Project, Buildroot, real-time,
graphics, boot time, debugging...

Bootlin logo

Elixir Cross Referencer

Open Menu /external/gpl3/gdb/dist/sim/ppc/emul_chirp.h 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
/*  This file is part of the program psim.

    Copyright (C) 1994-1997, Andrew Cagney <cagney@highland.com.au>

    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 3 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, see <http://www.gnu.org/licenses/>.
 
    */


#ifndef _EMUL_CHIRP_H_
#define _EMUL_CHIRP_H_

/* EMUL_CHIRP:

   The emulation of the OpenBoot client interface (as defined in 1275)
   illustrates how it is possible for PSIM to implement an interface
   that is both running in virtual memory and is called using a
   standard function call interface.

   The OpenBoot client interface is implemented by using two
   instructions:

   	client_interface:
		<emul_call>
		blr

   A client program makes a function call to `client_interface' using
   the `bl' instruction.  The simulator will then execute the
   <emul_call> instruction (which calls emul_chirp) and then the `blr'
   which will return to the caller.

   In addition to providing the `client_interface' entry point, while
   a client request is being handled, emul_chirp patches (well it will
   one day) the data access exception vector with a <emul_call>
   instruction.  By doing this, emul_chirp is able to catch and handle
   any invalid data accesses it makes while emulating a client call.

   When such an exception occures, emul_chirp is able to recover by
   restoring the processor and then calling the clients callback
   interface so that the client can recover from the data exception.

   Handling this are the emul_chirp states:

                              serving---.
                             /          |
   Emulation compleated     ^           v Client makes call to
     - restore int vectors  |           | emulated interface
                            ^           v   - patch exception vectors
                            |          /
                            `-emulating-. emulating the request
                             /          |
                            |           v Emulation encounters
   Client callback recovers ^           | data access exception
   from data exception and  |           v   - re-enable vm
   returns.                 ^           |   - call client callback
     - restart request      |          /
                            `--faulting
   */


extern const os_emul emul_chirp;

#endif