Interpreting GNAT exception tracebacks

Interpreting GNAT exception tracebacks

[Markus Schöpflin]

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 
<system__standard_library__adafinal@plt>
...
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