exception handling on PowerPC 405

QNX Newsgroups (Archives) qdn.public.qnxrtp.powerpc
1

Hi,

I am interested in finding out QNX exception handling code/capabilites for
the PowerPC 405.

In general, when an exception like a machine check or program exception
occurs, the 405 handles exceptions by switching to supervisory state,
saving the processor state to certain registers, and then jumping to an
exception handler routine. Each major type of exception has its own
exception
vector located at an absolute address. Exception handling is performed by
software linked to the appropriated vector offset.

How is all this setup in QNX Neutrino?

I’m interested in being able to save the important registers and stack
info in software log when an exception occurs.

Thanks.

2

eabrg <eabrg21@yahoo.com> wrote in message
news:br5665$1mu$1@tiger.openqnx.com…

I am interested in finding out QNX exception handling code/capabilites for
the PowerPC 405.

In general, when an exception like a machine check or program exception
occurs, the 405 handles exceptions by switching to supervisory state,
saving the processor state to certain registers, and then jumping to an
exception handler routine. Each major type of exception has its own
exception
vector located at an absolute address. Exception handling is performed by
software linked to the appropriated vector offset.

How is all this setup in QNX Neutrino?

I’m interested in being able to save the important registers and stack
info in software log when an exception occurs.

Depending on the exception, different actions are taken. Most exceptions or
trap conditions are indicated via a signal to the thread causing it (if it’s
a synchronous event). If it’s an asynchronous trap (ie. machine check
because of a bad entry not referenced until later), then a signal will be
dropped on whom ever is active - not necessarily the root cause thread.
Traps for page faults in the stack are handled transparently from the user,
as we fault in pages on demand for the stack.

There isn’t really any way for you to save or get at any of the registers at
exception time from a user land perspective.

What kind of information are you trying to get at? Many of the signals
related to things like pagefaults or bounds errors pass information such as
PC, and cause information.

-Adam

3

Adam Mallory wrote:

eabrg <> eabrg21@yahoo.com> > wrote in message
news:br5665$1mu$> 1@tiger.openqnx.com> …

I am interested in finding out QNX exception handling code/capabilites for
the PowerPC 405.

In general, when an exception like a machine check or program exception
occurs, the 405 handles exceptions by switching to supervisory state,
saving the processor state to certain registers, and then jumping to an
exception handler routine. Each major type of exception has its own
exception
vector located at an absolute address. Exception handling is performed by
software linked to the appropriated vector offset.

How is all this setup in QNX Neutrino?

I’m interested in being able to save the important registers and stack
info in software log when an exception occurs.

Depending on the exception, different actions are taken. Most exceptions or
trap conditions are indicated via a signal to the thread causing it (if it’s
a synchronous event). If it’s an asynchronous trap (ie. machine check
because of a bad entry not referenced until later), then a signal will be
dropped on whom ever is active - not necessarily the root cause thread.
Traps for page faults in the stack are handled transparently from the user,
as we fault in pages on demand for the stack.

There isn’t really any way for you to save or get at any of the registers at
exception time from a user land perspective.

What kind of information are you trying to get at? Many of the signals
related to things like pagefaults or bounds errors pass information such as
PC, and cause information.

-Adam

Thanks Adam.

With signals, I would have to register the signal condition in each
thread. Isn’t it?

I presume that when an exception condition occurs, an interrupt is
generated.
Can I then make use of interruptAttach() and register my handler function
with it.

What interrupt vector do I use when I call interruptAttach().?
In PowerPC 405, the exception vector offset for the exceptions is defined
from 0x0100 to 0x2000. How does this relate to the interrput vector # to
use in interruptAttach()?

In the registered function handler, I am interested in retrieving the
contents of the following registers: general purpose registers (GPR),
machine state register (MSR), save/restore registers (SRR0, SRR1, SRR2,
SRR3), exception vector prefix register (EVPR), exception syndrom register
(ESR) and the stack traceback.

4

eabrg <eabrg21@yahoo.com> wrote in message
news:br8d98$qlq$1@tiger.openqnx.com…

With signals, I would have to register the signal condition in each
thread. Isn’t it?

Well signal registeration is per process, but certain signals can target
specific threads of execution (namly syncronous signals).

I presume that when an exception condition occurs, an interrupt is
generated.
Can I then make use of interruptAttach() and register my handler function
with it.

You presume wrong. When a exception occurs, its handler is called. If that
vector represents an external interrupt from a controller/device then we
start the interrupt handler call for that level (after decoding the level
etc). When a machine check occurs, we don’t do the interrupt handler
subsystem, so attaching won’t do any good.

What interrupt vector do I use when I call interruptAttach().?
In PowerPC 405, the exception vector offset for the exceptions is defined
from 0x0100 to 0x2000. How does this relate to the interrput vector # to
use in interruptAttach()?

In the registered function handler, I am interested in retrieving the
contents of the following registers: general purpose registers (GPR),
machine state register (MSR), save/restore registers (SRR0, SRR1, SRR2,
SRR3), exception vector prefix register (EVPR), exception syndrom register
(ESR) and the stack traceback.

If you want to review those registers at exception time, you’ll need to get
a hardware debugger to do that. The kernel doesn’t export those values
directly. Perhaps you should give some background into what and why your
trying to do this - there could be a better way.

-Adam

5

Adam Mallory wrote:

eabrg <> eabrg21@yahoo.com> > wrote in message
news:br8d98$qlq$> 1@tiger.openqnx.com> …

With signals, I would have to register the signal condition in each
thread. Isn’t it?

Well signal registeration is per process, but certain signals can target
specific threads of execution (namly syncronous signals).

I presume that when an exception condition occurs, an interrupt is
generated.
Can I then make use of interruptAttach() and register my handler function
with it.

You presume wrong. When a exception occurs, its handler is called. If that
vector represents an external interrupt from a controller/device then we
start the interrupt handler call for that level (after decoding the level
etc). When a machine check occurs, we don’t do the interrupt handler
subsystem, so attaching won’t do any good.

What interrupt vector do I use when I call interruptAttach().?
In PowerPC 405, the exception vector offset for the exceptions is defined
from 0x0100 to 0x2000. How does this relate to the interrput vector # to
use in interruptAttach()?

In the registered function handler, I am interested in retrieving the
contents of the following registers: general purpose registers (GPR),
machine state register (MSR), save/restore registers (SRR0, SRR1, SRR2,
SRR3), exception vector prefix register (EVPR), exception syndrom register
(ESR) and the stack traceback.

If you want to review those registers at exception time, you’ll need to get
a hardware debugger to do that. The kernel doesn’t export those values
directly. Perhaps you should give some background into what and why your
trying to do this - there could be a better way.

-Adam

OK. Let me give some background about why I need this.

When an exception occurs, I want to store the “state” of the processor
into non volatile storage before the system is reset. By “state” I mean
any information that may be useful in helping diagnose the problem or at
least identify the source of the problem. The register dump and the stack
traceback are two pieces of information that will help me do that.

In non-Linux like RTOSes (like VxWorks, Nucleus), there is the ability to
register user defined fns for each vector offset and then retrieved the
desired “state” of the processor through C library calls. This is all done
in the context of an exception thread/process. So there is one single
process that collects this information when an exception condition occurs.

6

“eabrg” <eabrg21@yahoo.com> wrote in message
news:bradfo$25k$1@tiger.openqnx.com…

Adam Mallory wrote:

eabrg <> eabrg21@yahoo.com> > wrote in message
news:br8d98$qlq$> 1@tiger.openqnx.com> …

With signals, I would have to register the signal condition in each
thread. Isn’t it?

Well signal registeration is per process, but certain signals can target
specific threads of execution (namly syncronous signals).

I presume that when an exception condition occurs, an interrupt is
generated.
Can I then make use of interruptAttach() and register my handler
function
with it.

You presume wrong. When a exception occurs, its handler is called. If
that
vector represents an external interrupt from a controller/device then we
start the interrupt handler call for that level (after decoding the
level
etc). When a machine check occurs, we don’t do the interrupt handler
subsystem, so attaching won’t do any good.

What interrupt vector do I use when I call interruptAttach().?
In PowerPC 405, the exception vector offset for the exceptions is
defined
from 0x0100 to 0x2000. How does this relate to the interrput vector #
to
use in interruptAttach()?

In the registered function handler, I am interested in retrieving the
contents of the following registers: general purpose registers (GPR),
machine state register (MSR), save/restore registers (SRR0, SRR1,
SRR2,
SRR3), exception vector prefix register (EVPR), exception syndrom
register
(ESR) and the stack traceback.

If you want to review those registers at exception time, you’ll need to
get
a hardware debugger to do that. The kernel doesn’t export those values
directly. Perhaps you should give some background into what and why
your
trying to do this - there could be a better way.

-Adam


OK. Let me give some background about why I need this.

When an exception occurs, I want to store the “state” of the processor
into non volatile storage before the system is reset. By “state” I mean
any information that may be useful in helping diagnose the problem or at
least identify the source of the problem. The register dump and the stack
traceback are two pieces of information that will help me do that.

In non-Linux like RTOSes (like VxWorks, Nucleus), there is the ability to
register user defined fns for each vector offset and then retrieved the
desired “state” of the processor through C library calls. This is all done
in the context of an exception thread/process. So there is one single
process that collects this information when an exception condition occurs.

Look at documentation for dumper (i’m assuming it’s available for PowerPc),
it’s a start.

7

eabrg <eabrg21@yahoo.com> wrote in message
news:bradfo$25k$1@tiger.openqnx.com…

When an exception occurs, I want to store the “state” of the processor
into non volatile storage before the system is reset. By “state” I mean
any information that may be useful in helping diagnose the problem or at
least identify the source of the problem. The register dump and the stack
traceback are two pieces of information that will help me do that.

I understood what you wanted, I’m more interested in what problem you’re
trying to solve (ie. perhaps it’s a problem others have seen before and ca
offer help). Unfortunately, there really isn’t a nice way to do what you’re
asking without a hardware debugger to do the state examination.
Technically, you could locate the exeception vector table (it’s in the low
end of memory) and chain your own vector into the table.

In non-Linux like RTOSes (like VxWorks, Nucleus), there is the ability to
register user defined fns for each vector offset and then retrieved the
desired “state” of the processor through C library calls. This is all done
in the context of an exception thread/process. So there is one single
process that collects this information when an exception condition occurs.

I’m not sure what a ‘non-Linux’ RTOS means, but I’ll assume it’s a
non-memory protected, flat-address space OS. Again, no we don’t provide an
API to hook into the execption table for PowerPC.

-Adam