* Unhandled Exception in Tartan generated code for M68040 @ 2017-07-07 9:58 Petter Fryklund 2017-07-07 16:05 ` Anh Vo 2017-07-12 19:30 ` Niklas Holsti 0 siblings, 2 replies; 10+ messages in thread From: Petter Fryklund @ 2017-07-07 9:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Unhandled Exception in Tartan generated code for M68040 2017-07-07 9:58 Unhandled Exception in Tartan generated code for M68040 Petter Fryklund @ 2017-07-07 16:05 ` Anh Vo 2017-07-07 16:09 ` Simon Wright 2017-07-12 15:20 ` Petter Fryklund 2017-07-12 19:30 ` Niklas Holsti 1 sibling, 2 replies; 10+ messages in thread From: Anh Vo @ 2017-07-07 16:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Unhandled Exception in Tartan generated code for M68040 2017-07-07 16:05 ` Anh Vo @ 2017-07-07 16:09 ` Simon Wright 2017-07-12 15:20 ` Petter Fryklund 1 sibling, 0 replies; 10+ messages in thread From: Simon Wright @ 2017-07-07 16:09 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Unhandled Exception in Tartan generated code for M68040 2017-07-07 16:05 ` Anh Vo 2017-07-07 16:09 ` Simon Wright @ 2017-07-12 15:20 ` Petter Fryklund 1 sibling, 0 replies; 10+ messages in thread From: Petter Fryklund @ 2017-07-12 15:20 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Unhandled Exception in Tartan generated code for M68040 2017-07-07 9:58 Unhandled Exception in Tartan generated code for M68040 Petter Fryklund 2017-07-07 16:05 ` Anh Vo @ 2017-07-12 19:30 ` Niklas Holsti 2017-08-07 5:48 ` Petter Fryklund 1 sibling, 1 reply; 10+ messages in thread From: Niklas Holsti @ 2017-07-12 19:30 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Unhandled Exception in Tartan generated code for M68040 2017-07-12 19:30 ` Niklas Holsti @ 2017-08-07 5:48 ` Petter Fryklund 2017-08-07 6:21 ` Niklas Holsti 0 siblings, 1 reply; 10+ messages in thread From: Petter Fryklund @ 2017-08-07 5:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Unhandled Exception in Tartan generated code for M68040 2017-08-07 5:48 ` Petter Fryklund @ 2017-08-07 6:21 ` Niklas Holsti 2017-08-08 5:33 ` Petter Fryklund 0 siblings, 1 reply; 10+ messages in thread From: Niklas Holsti @ 2017-08-07 6:21 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Unhandled Exception in Tartan generated code for M68040 2017-08-07 6:21 ` Niklas Holsti @ 2017-08-08 5:33 ` Petter Fryklund 2017-08-16 11:04 ` Petter Fryklund 0 siblings, 1 reply; 10+ messages in thread From: Petter Fryklund @ 2017-08-08 5:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Unhandled Exception in Tartan generated code for M68040 2017-08-08 5:33 ` Petter Fryklund @ 2017-08-16 11:04 ` Petter Fryklund 2017-09-04 8:46 ` Petter Fryklund 0 siblings, 1 reply; 10+ messages in thread From: Petter Fryklund @ 2017-08-16 11:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Unhandled Exception in Tartan generated code for M68040 2017-08-16 11:04 ` Petter Fryklund @ 2017-09-04 8:46 ` Petter Fryklund 0 siblings, 0 replies; 10+ messages in thread From: Petter Fryklund @ 2017-09-04 8:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-09-04 8:46 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-07-07 9:58 Unhandled Exception in Tartan generated code for M68040 Petter Fryklund 2017-07-07 16:05 ` Anh Vo 2017-07-07 16:09 ` Simon Wright 2017-07-12 15:20 ` Petter Fryklund 2017-07-12 19:30 ` Niklas Holsti 2017-08-07 5:48 ` Petter Fryklund 2017-08-07 6:21 ` Niklas Holsti 2017-08-08 5:33 ` Petter Fryklund 2017-08-16 11:04 ` Petter Fryklund 2017-09-04 8:46 ` Petter Fryklund
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox