Re: Unhandled Exception in Tartan generated code for M68040

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

Den tisdag 8 augusti 2017 kl. 07:33:07 UTC+2 skrev Petter Fryklund:
> 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

I think that exceptions raise from an exception handler can cause unhandled exception if there is no handler one level up. 

I've learned that the hexadecimal value is indeed an address that can be matched to the .map file produced by the build.

Regards,
Petter