Re: Unhandled Exception in Tartan generated code for M68040

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 17-08-07 08:48 , Petter Fryklund wrote:
> Den onsdag 12 juli 2017 kl. 21:30:28 UTC+2 skrev Niklas Holsti:
>> On 17-07-07 12:58 , Petter Fryklund wrote:
>>> Hi, I'm trying to locate an Unhandled Exception. The printout
>>> received is
>>>
>>> Unhandled Exception vector 37 at 45E6C
>>>
>>> or
>>>
>>> Unhandled Exception vector 18 at 10A40E
>>>
>>> I assume there is a way to use the .map file to find out where these
>>> exceptions occur, but endless googling has come up with nil.
>>
>> And in another message, Petter continued:
>>
>>  > the Unexpected Exception is erronous, the code has exception
>>  > handler everywhere.
>>
>> Are you sure, Petter, that "exception" in "Unhandled Exception" means an
>> Ada exception? I seem to remember that some processors use the term
>> "exception" for what is more commonly called a "trap". Perhaps these are
>> HW traps that are _not_ mapped to Ada exceptions?
>>
>> The Wikipedia page on M68000
>> (https://en.wikipedia.org/wiki/Motorola_68000_series) uses the term
>> "exception" for HW events,and so does the M68040 User Manual
>> (http://cache.freescale.com/files/32bit/doc/ref_manual/MC68040UM.pdf).
>>
>> Table 8-1 in the User Manual lists these HW exceptions, by number. It
>> seems that numbers 32..47 are of SW origin, triggered by the TRAP
>> instruction, while number 18 is described as "Unassigned, Reserved".
>> Numbers 25..31 are "Interrupt Autovectors". This suggests that these HW
>> exceptions should be treated as interrupts in the Ada program, that is,
>> processed by interrupt handlers, not by exception handlers. On the other
>> hand, the Tartan run-time system may map some of these HW exceptions to
>> Ada exceptions, for example number 5, which is "Integer Divide by Zero".
>>
>> (Disclaimer: I know nothing about the Tartan compiler.)
>>
>> --
>> Niklas Holsti
>> Tidorum Ltd
>> niklas holsti tidorum fi
>>        .      @       .
>
> Thanks for responding, Niklas.
> Your suggestion makes sense since one would expect the program to stop
> on an Unhandled Exception, but it continues.

It is not evident what one would expect. Standard Ada says that an 
unhandled Ada exception in a task should terminate that task (which 
usually happens silently), but the other tasks should continue.

If your Unhandled Exceptions are not Ada exceptions, but HW traps, and 
the program is embedded, the system designer may prefer to have the 
program continue after an unexpected (unhandled) HW trap, or have it 
stop, depending on the criticality (safety requirements) of the program 
and on the presence or absence of redundancy or fail-safe external 
subsystems.

The Ariane 501 accident is an example where stopping the program was the 
wrong action in that context.

> But I cannot figure out
> what the 6 digit hex number is in that case.

I would expect the number to be the memory address of the instruction at 
which the HW trap occurred (whether or not this instruction is the 
direct cause of the trap). I assume you have searched the .map file for 
these addresses, but usually the .map does not contain the address of 
every instruction, only of the subprogram entry points. By comparing the 
hex numbers with the subprogram entry points, and assuming that all code 
in subprogram A lies between the entry point of A and the next entry 
point in address order (which is not a safe assumption for all 
compilers), you should be able to find the subprogram that contains the 
relevant instruction.

Or you could ask for a full disassembly of the program and search there 
for these hex numbers.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .