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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,4233bc6539bdd190,start X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.66.78.6 with SMTP id x6mr327886paw.42.1354794898598; Thu, 06 Dec 2012 03:54:58 -0800 (PST) Path: 6ni30359pbd.1!nntp.google.com!news.glorb.com!us.feeder.erje.net!feeder.erje.net!eu.feeder.erje.net!news2.arglkargh.de!news.mixmin.net!aioe.org!.POSTED!not-for-mail From: =?ISO-8859-15?Q?Markus_Sch=F6pflin?= Newsgroups: comp.lang.ada Subject: Interpreting GNAT exception tracebacks Date: Thu, 06 Dec 2012 12:55:00 +0100 Organization: Aioe.org NNTP Server Message-ID: NNTP-Posting-Host: MdpKeRr+sx3LK7JQiK5aNw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-12-06T12:55:00+01:00 List-Id: Hello, I have been looking at an exception traceback produced by GNAT (4.4.5 on Debian x86_64). The problem is that the traceback doesn't match the assembler code, or at least it doesn't match what I would be expecting. Consider the following short program: ---%<--- procedure TRACE is FOO : INTEGER range 0 .. 10; begin FOO := 11; end; --->%--- Compiling and running it gives: ---%<--- > gnatmake -g -O2 trace.adb -bargs -E && ./trace gcc-4.4 -c -g -O2 trace.adb trace.adb:4:11: warning: value not in range of subtype of "Standard.Integer" defined at line 2 trace.adb:4:11: warning: "Constraint_Error" will be raised at run time gnatbind -E -x trace.ali gnatlink trace.ali -g Execution terminated by unhandled exception Exception name: CONSTRAINT_ERROR Message: trace.adb:4 range check failed Call stack traceback locations: 0x401331 0x401308 0x7f298b558c8b 0x401117 --->%--- The addr2line output for this call stack looks OK. But when disassembling the generated code the addresses don't match the assembler code: ---%<--- > objdump -dl trace ... /.../trace/b~trace.adb:120 401300: e8 d3 fd ff ff callq 4010d8 <__gnat_break_start@plt> /.../trace/b~trace.adb:121 401305: e8 16 00 00 00 callq 401320 <_ada_trace> /.../trace/b~trace.adb:122 40130a: e8 99 fd ff ff callq 4010a8 ... 0000000000401320 <_ada_trace>: _ada_trace(): /.../trace/trace.adb:1 401320: 48 83 ec 08 sub $0x8,%rsp /.../trace/trace.adb:4 401324: be 04 00 00 00 mov $0x4,%esi 401329: bf 2e 14 40 00 mov $0x40142e,%edi 40132e: e8 95 fd ff ff callq 4010c8 <__gnat_rcheck_12@plt> 401333: 90 nop 401334: 90 nop ... --->%--- What I would have expected is that the first address from the stack trace (0x401331) matches the starting address of a machine instruction (most likely 0x40132e), but this is not the case. And also not for the second address from the stack trace. It looks like the addresses from the stack trace point 4 bytes behind the expected location. Now, are my expectations wrong? Anyone knows what's going on here? TIA, Markus