Re: Unhandled Exception in Tartan generated code for M68040

[Petter Fryklund <petter.fryklund@atero.se>]

Den måndag 7 augusti 2017 kl. 08:21:29 UTC+2 skrev Niklas Holsti:
> 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
>        .      @       .

Hi again.
I've inspected the s-record file and it seems like the printout comes from the runtime unit unhandledexception in the standalone runtime. There are only a few tasks in the program and one of them doesn't have exception handlers. So I will fix that and see what the root cause is.

Regards,
Petter