From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.98.160.136 with SMTP id p8mr714709pfl.29.1502881499571; Wed, 16 Aug 2017 04:04:59 -0700 (PDT) X-Received: by 10.36.122.82 with SMTP id a79mr72309itc.13.1502881499418; Wed, 16 Aug 2017 04:04:59 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!feed.usenet.farm!feeder4.usenet.farm!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!m34no282404iti.0!news-out.google.com!19ni533itw.0!nntp.google.com!m34no282400iti.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 16 Aug 2017 04:04:59 -0700 (PDT) In-Reply-To: <0209a603-ce92-40c4-a30e-1541aa58fc15@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=136.163.203.6; posting-account=g0yTkgoAAADdZGEYyZahxGlO3EkjH0Wv NNTP-Posting-Host: 136.163.203.6 References: <0209a603-ce92-40c4-a30e-1541aa58fc15@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Unhandled Exception in Tartan generated code for M68040 From: Petter Fryklund Injection-Date: Wed, 16 Aug 2017 11:04:59 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:47730 Date: 2017-08-16T04:04:59-07:00 List-Id: Den tisdag 8 augusti 2017 kl. 07:33:07 UTC+2 skrev Petter Fryklund: > Den m=C3=A5ndag 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 thes= e > > >>> 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" mean= s 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. I= t > > >> 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 o= ther > > >> 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 Ze= ro". > > >> > > >> (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 sto= p > > > on an Unhandled Exception, but it continues. > >=20 > > It is not evident what one would expect. Standard Ada says that an=20 > > unhandled Ada exception in a task should terminate that task (which=20 > > usually happens silently), but the other tasks should continue. > >=20 > > If your Unhandled Exceptions are not Ada exceptions, but HW traps, and= =20 > > the program is embedded, the system designer may prefer to have the=20 > > program continue after an unexpected (unhandled) HW trap, or have it=20 > > stop, depending on the criticality (safety requirements) of the program= =20 > > and on the presence or absence of redundancy or fail-safe external=20 > > subsystems. > >=20 > > The Ariane 501 accident is an example where stopping the program was th= e=20 > > wrong action in that context. > >=20 > > > But I cannot figure out > > > what the 6 digit hex number is in that case. > >=20 > > I would expect the number to be the memory address of the instruction a= t=20 > > which the HW trap occurred (whether or not this instruction is the=20 > > direct cause of the trap). I assume you have searched the .map file for= =20 > > these addresses, but usually the .map does not contain the address of= =20 > > every instruction, only of the subprogram entry points. By comparing th= e=20 > > hex numbers with the subprogram entry points, and assuming that all cod= e=20 > > in subprogram A lies between the entry point of A and the next entry=20 > > point in address order (which is not a safe assumption for all=20 > > compilers), you should be able to find the subprogram that contains the= =20 > > relevant instruction. > >=20 > > Or you could ask for a full disassembly of the program and search there= =20 > > for these hex numbers. > >=20 > > --=20 > > Niklas Holsti > > Tidorum Ltd > > niklas holsti tidorum fi > > . @ . >=20 > Hi again. > I've inspected the s-record file and it seems like the printout comes fro= m 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 hand= lers. So I will fix that and see what the root cause is. >=20 > Regards, > Petter I think that exceptions raise from an exception handler can cause unhandled= exception if there is no handler one level up.=20 I've learned that the hexadecimal value is indeed an address that can be ma= tched to the .map file produced by the build. Regards, Petter