Unhandled Exception in Tartan generated code for M68040

Unhandled Exception in Tartan generated code for M68040

[Petter Fryklund]

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.

Can anybody give a hint?

Regards,
Petter

Re: Unhandled Exception in Tartan generated code for M68040

[Anh Vo]

On Friday, July 7, 2017 at 2:58:05 AM UTC-7, 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.
> 
> Can anybody give a hint?

I never use Tartan compiler before. So, I do not know much about it. This advice is just a guess. The source triggering the exception can be determined with addr2line utility.

Anh Vo 

Re: Unhandled Exception in Tartan generated code for M68040

[Simon Wright]

Anh Vo <anhvofrcaus@gmail.com> writes:

> The source triggering the exception can be determined with addr2line
> utility.

That depends on the host/compiler/target. Tartan may have their own
equivalent.

Re: Unhandled Exception in Tartan generated code for M68040

[Petter Fryklund]

Den fredag 7 juli 2017 kl. 18:05:50 UTC+2 skrev Anh Vo:
> On Friday, July 7, 2017 at 2:58:05 AM UTC-7, 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.
> > 
> > Can anybody give a hint?
> 
> I never use Tartan compiler before. So, I do not know much about it. This advice is just a guess. The source triggering the exception can be determined with addr2line utility.
> 
> Anh Vo

Thanks for replying.

One might think that the hexadecimal numbers are addresses, but it is, the Unexpected Exception is erronous, the code has exception handler everywhere.

Re: Unhandled Exception in Tartan generated code for M68040

[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
       .      @       .

Re: Unhandled Exception in Tartan generated code for M68040

[Petter Fryklund]

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. But I cannot figure out what the 6 digit hex number is in that case.

Regards,
Petter 

Re: Unhandled Exception in Tartan generated code for M68040

[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
       .      @       .

Re: Unhandled Exception in Tartan generated code for M68040

[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

Re: Unhandled Exception in Tartan generated code for M68040

[Petter Fryklund]

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

Re: Unhandled Exception in Tartan generated code for M68040

[Petter Fryklund]

I have now solved my problem. Usage of uninitiated data can cause unhandled exception in Tartan generated code on M68040 even if there are exception handlers all the way up (what is up and what is down?).

Reagrads,
Petter