GNAT compiler versions and addr2line

GNAT compiler versions and addr2line

[Phil]

Hi,

I'm having problems getting useful debugging data from some GNAT
versions.  If I use the Debian FSF version (6.3.0), I get very little
useful unless running inside gdb.  In particular, the trace addresses
don't resolve to anything through addr2line.

Given this test program:
    $ cat foo.adb
    procedure Foo is

       procedure Able is
       begin
	  raise Constraint_Error with "It broke";
       end Able;

       procedure Baker is
       begin
	  Able;
       end Baker;

    begin
       Baker;
    end Foo;

Check the compiler version:

    $ gnatmake --version
    GNATMAKE 6.3.0
    […]

Build with debug info and binder argument -E:

    $ gnatmake -g foo -bargs -E
    […]

Run and try to use addr2line to get more information:
    $ ./foo
    Execution terminated by unhandled exception
    raised CONSTRAINT_ERROR : It broke
    Call stack traceback locations:
    0x55654f763530 0x55654f763566 0x55654f76354c 0x55654f7634e8 0x7f11a88292df 0x55654f763238 0xfffffffffffffffe

    $ addr2line -e foo -f 0x55654f763530 0x55654f763566 0x55654f76354c 0x55654f7634e8 0x7f11a88292df 0x55654f763238 0xfffffffffffffffe
    ??
    ??:0
    […and repeats ??, ??:0…]

Now, gdb using “catch exception” and “bt” will show some debugging:
    (gdb) bt
    #0  <__gnat_debug_raise_exception> (e=0x5555557560c0 <constraint_error>, 
	message=...) at s-excdeb.adb:40
    #1  0x00007ffff797603e in ada.exceptions.complete_occurrence (
	x=x@entry=0x555555757050) at a-except.adb:925
    #2  0x00007ffff797604d in ada.exceptions.complete_and_propagate_occurrence (
	x=x@entry=0x555555757050) at a-except.adb:936
    #3  0x00007ffff79760a0 in <__gnat_raise_exception> (
	e=0x5555557560c0 <constraint_error>, message=...) at a-except.adb:978
    #4  0x0000555555555532 in foo.able () at foo.adb:5
    #5  0x0000555555555568 in foo.baker () at foo.adb:10
    #6  0x000055555555554e in foo () at foo.adb:14
So the debugging data is accessible (somehow).

The same problem occurs with version 7.3.0 (from Debian unstable).  It
works if I use the current AdaCore community version instead:

    $ gnatmake --version
    GNATMAKE Community 2018 (20180524-73)
    $ ./foo 

    Execution of ./foo terminated by unhandled exception
    raised CONSTRAINT_ERROR : It broke
    Call stack traceback locations:
    0x4024e4 0x402519 0x402500 0x402473 0x7fb92acb72df 0x4020b8 0xfffffffffffffffe
    $ addr2line -e foo -f 0x4024e4 0x402519 0x402500 0x402473 0x7fb92acb72df 0x4020b8 0xfffffffffffffffe
    foo__able
    /tmp/ada/foo.adb:5
    foo__baker
    /tmp/ada/foo.adb:10
    _ada_foo
    /tmp/ada/foo.adb:14
    main
    /tmp/ada/b~foo.adb:185
    […]


I started looking at this because of problems using GNAT.Traceback.Symbolic
(the 6.3.0 version has a stub version isn't useful).  Getting
addr2line working would be very helpful.  I assume (hope!) it's a
PBCAK issue — does anyone have a suggestion for getting addr2line
working with the Debian/FSF versions? Am I missing something on the
command line?

TIA,

Phil.

Re: GNAT compiler versions and addr2line

[Egil H H]

On Wednesday, August 22, 2018 at 3:02:00 PM UTC+2, Phil wrote:
> 

Always use the addr2line supplied with the version of GNAT you are using

Re: GNAT compiler versions and addr2line

[gautier_niouzes]

Did you try "gnatmake -g foo -bargs -Es" (note the 's' at the end) ?

Re: GNAT compiler versions and addr2line

[Phil]

Egil H H <ehh.public@gmail.com> wrote:
> On Wednesday, August 22, 2018 at 3:02:00 PM UTC+2, Phil wrote:
> > 

> Always use the addr2line supplied with the version of GNAT you are using

Yup, doing that.  Any other suggestions?

Ta,
Phil.

Re: GNAT compiler versions and addr2line

[Phil]

gautier_niouzes@hotmail.com wrote:
> Did you try "gnatmake -g foo -bargs -Es" (note the 's' at the end) ?

Yup, I tried that too — no difference. :-(
(Just checked again to be sure.)

Re: GNAT compiler versions and addr2line

[Alejandro R. Mosteo]

On 22/08/18 15:01, Phil wrote:
> Hi,
> 
> I'm having problems getting useful debugging data from some GNAT
> versions.  If I use the Debian FSF version (6.3.0), I get very little
> useful unless running inside gdb.  In particular, the trace addresses
> don't resolve to anything through addr2line.

I have seen the same up to current 7.3 FSF Ubuntu versions, and still 
haven't found a workaround :/

Alex.

> 
> Given this test program:
>      $ cat foo.adb
>      procedure Foo is
> 
>         procedure Able is
>         begin
> 	  raise Constraint_Error with "It broke";
>         end Able;
> 
>         procedure Baker is
>         begin
> 	  Able;
>         end Baker;
> 
>      begin
>         Baker;
>      end Foo;
> 
> Check the compiler version:
> 
>      $ gnatmake --version
>      GNATMAKE 6.3.0
>      […]
> 
> Build with debug info and binder argument -E:
> 
>      $ gnatmake -g foo -bargs -E
>      […]
> 
> Run and try to use addr2line to get more information:
>      $ ./foo
>      Execution terminated by unhandled exception
>      raised CONSTRAINT_ERROR : It broke
>      Call stack traceback locations:
>      0x55654f763530 0x55654f763566 0x55654f76354c 0x55654f7634e8 0x7f11a88292df 0x55654f763238 0xfffffffffffffffe
> 
>      $ addr2line -e foo -f 0x55654f763530 0x55654f763566 0x55654f76354c 0x55654f7634e8 0x7f11a88292df 0x55654f763238 0xfffffffffffffffe
>      ??
>      ??:0
>      […and repeats ??, ??:0…]
> 
> Now, gdb using “catch exception” and “bt” will show some debugging:
>      (gdb) bt
>      #0  <__gnat_debug_raise_exception> (e=0x5555557560c0 <constraint_error>,
> 	message=...) at s-excdeb.adb:40
>      #1  0x00007ffff797603e in ada.exceptions.complete_occurrence (
> 	x=x@entry=0x555555757050) at a-except.adb:925
>      #2  0x00007ffff797604d in ada.exceptions.complete_and_propagate_occurrence (
> 	x=x@entry=0x555555757050) at a-except.adb:936
>      #3  0x00007ffff79760a0 in <__gnat_raise_exception> (
> 	e=0x5555557560c0 <constraint_error>, message=...) at a-except.adb:978
>      #4  0x0000555555555532 in foo.able () at foo.adb:5
>      #5  0x0000555555555568 in foo.baker () at foo.adb:10
>      #6  0x000055555555554e in foo () at foo.adb:14
> So the debugging data is accessible (somehow).
> 
> The same problem occurs with version 7.3.0 (from Debian unstable).  It
> works if I use the current AdaCore community version instead:
> 
>      $ gnatmake --version
>      GNATMAKE Community 2018 (20180524-73)
>      $ ./foo
> 
>      Execution of ./foo terminated by unhandled exception
>      raised CONSTRAINT_ERROR : It broke
>      Call stack traceback locations:
>      0x4024e4 0x402519 0x402500 0x402473 0x7fb92acb72df 0x4020b8 0xfffffffffffffffe
>      $ addr2line -e foo -f 0x4024e4 0x402519 0x402500 0x402473 0x7fb92acb72df 0x4020b8 0xfffffffffffffffe
>      foo__able
>      /tmp/ada/foo.adb:5
>      foo__baker
>      /tmp/ada/foo.adb:10
>      _ada_foo
>      /tmp/ada/foo.adb:14
>      main
>      /tmp/ada/b~foo.adb:185
>      […]
> 
> 
> I started looking at this because of problems using GNAT.Traceback.Symbolic
> (the 6.3.0 version has a stub version isn't useful).  Getting
> addr2line working would be very helpful.  I assume (hope!) it's a
> PBCAK issue — does anyone have a suggestion for getting addr2line
> working with the Debian/FSF versions? Am I missing something on the
> command line?
> 
> TIA,
> 
> Phil.
> 
> 
> 
> 

Re: GNAT compiler versions and addr2line

[Jeffrey R. Carter]

On 08/22/2018 03:01 PM, Phil wrote:
> 
> I'm having problems getting useful debugging data from some GNAT
> versions.  If I use the Debian FSF version (6.3.0), I get very little
> useful unless running inside gdb.  In particular, the trace addresses
> don't resolve to anything through addr2line.
 >
> The same problem occurs with version 7.3.0 (from Debian unstable).

Ubuntu has 8.0.1. I don't know if it would make a difference.

-- 
Jeff Carter
"He had no conception of the instrument. He
was blowing into it."
Take the Money and Run
135

Re: GNAT compiler versions and addr2line

[Phil]

Alejandro R. Mosteo <alejandro@mosteo.com> wrote:
> I have seen the same up to current 7.3 FSF Ubuntu versions, and still 
> haven't found a workaround :/

Ah, at least it's not just me!

Phil.

Re: GNAT compiler versions and addr2line

[Anh Vo]

On Wednesday, August 22, 2018 at 11:21:37 AM UTC-7, Phil wrote:
> Alejandro R. Mosteo <alejandro@mosteo.com> wrote:
> > I have seen the same up to current 7.3 FSF Ubuntu versions, and still 
> > haven't found a workaround :/
> 
> Ah, at least it's not just me!

gnatmake -g foo.adb -bargs -E for the following modified code. You will be pleasantly surprised that addr2line is not needed explicitly.

with Gnat.Traceback.Symbolic;
with Ada.Exceptions; use Ada;
with Ada.Text_IO; use Ada.Text_IO;

procedure Foo is 

   procedure Able is 
   begin 
      raise Constraint_Error with "It broke"; 
   end Able; 

   procedure Baker is 
   begin 
      Able; 
   end Baker;

begin 
   Baker; 
exception
   when Err : others =>
      Put_Line ("Houston we have a problem: " &
                                       Exceptions.Exception_Information(Err));
      Put_Line (GNAT.Traceback.Symbolic.Symbolic_Traceback(Err));
end Foo; 

Re: GNAT compiler versions and addr2line

[Randy Brukardt]

I can vouch for the fact that this works on our Debian server. It's a bit 
annoying to have to add code (as it has to be removed again when using the 
same code with other Ada compiler (Janus/Ada in my case), but it works and I 
couldn't really use Ada without it (too used to the Janus/Ada version). At 
least in most cases there are other things (like rep. clauses) that need 
change as well.

                                Randy.

"Anh Vo" <anhvofrcaus@gmail.com> wrote in message 
news:dbf742f5-1bd4-4903-8299-8739e6179bfc@googlegroups.com...
> On Wednesday, August 22, 2018 at 11:21:37 AM UTC-7, Phil wrote:
>> Alejandro R. Mosteo <alejandro@mosteo.com> wrote:
>> > I have seen the same up to current 7.3 FSF Ubuntu versions, and still
>> > haven't found a workaround :/
>>
>> Ah, at least it's not just me!
>
> gnatmake -g foo.adb -bargs -E for the following modified code. You will be 
> pleasantly surprised that addr2line is not needed explicitly.
>
> with Gnat.Traceback.Symbolic;
> with Ada.Exceptions; use Ada;
> with Ada.Text_IO; use Ada.Text_IO;
>
> procedure Foo is
>
>   procedure Able is
>   begin
>      raise Constraint_Error with "It broke";
>   end Able;
>
>   procedure Baker is
>   begin
>      Able;
>   end Baker;
>
> begin
>   Baker;
> exception
>   when Err : others =>
>      Put_Line ("Houston we have a problem: " &
> 
> Exceptions.Exception_Information(Err));
>      Put_Line (GNAT.Traceback.Symbolic.Symbolic_Traceback(Err));
> end Foo;
>
>
> 

Re: GNAT compiler versions and addr2line

[Brian Drummond]

On Wed, 22 Aug 2018 13:01:58 +0000, Phil wrote:

> Hi,
> 
> I'm having problems getting useful debugging data from some GNAT
> versions.  If I use the Debian FSF version (6.3.0), I get very little
> useful unless running inside gdb.  In particular, the trace addresses
> don't resolve to anything through addr2line.
> 
Basically Debian changed its policy (possibly for security reasons) 
regarding Address Space Randomisation and position-independent 
executables - not sure exactly what, perhaps they turned on PIE by 
default, to allow address space randomisation. I've seen all those 5555s 
in addresses so treated... (not so random, then?)

Anyway, apparently addr2line doesn't work so well with random addresses...

My "solution" is to suppress PIE, at least while debugging.

gpr snippet...

   package Compiler is
      for Default_Switches ("Ada") use ("-g", "-O1", "-gnatafo", "-
gnatq", "-gnatQ", "-gnateE");
   end Compiler;
   package Binder is
      for Default_Switches ("Ada") use ("-E");
   end Binder;
   package Linker is
      for Default_Switches ("Ada") use ("-g", "-no-pie");
   end Linker;

At the very least, -no-pie to the linker is necessary,  some of the 
others are necessary to get the traceback.

Still on the lookout for a better answer too.

-- Brian

Re: GNAT compiler versions and addr2line

[Simon Wright]

Brian Drummond <brian@shapes.demon.co.uk> writes:

> Basically Debian changed its policy (possibly for security reasons)
> regarding Address Space Randomisation and position-independent
> executables - not sure exactly what, perhaps they turned on PIE by
> default, to allow address space randomisation. I've seen all those
> 5555s in addresses so treated... (not so random, then?)
>
> Anyway, apparently addr2line doesn't work so well with random
> addresses...

On the Mac, we used to use -no_pie (in fact, I think it was the default,
not sure) but nowadays pie is enabled and we see

   $ ~/tmp/raiser

   Execution of /Users/simon/tmp/raiser terminated by unhandled exception
   raised PROGRAM_ERROR : raiser.adb:3 explicit raise
   Load address: 0x103df0000                         <==========
   Call stack traceback locations:
   0x103df0cc1 0x103df0c64

and the equivalent of addr2line, atos, lets us specify the actual load
address with -l:

   $ atos -o ~/tmp/raiser -l 0x103df0000 0x103df0cc1 0x103df0c64
   _ada_raiser (in raiser) (raiser.adb:3)
   main (in raiser) (b~raiser.adb:158)

AdaCore provided the VxWorks port with a utility vxaddr2line (??)
which was a shell wrapper round the powerpc-wrs-vxworks-addr2line; I
never looked into it, but I suppose it fixed up the addresses reported
in the stack dump (which were AFAICR relative to address 0) by adding
the actual load address passed as the first address argument.

Something similar might be done on Debian, but of course you'd have to
know tha actual load address .. determined at runtime .. so it means a
change to GNAT to report the load address in the stack dump.

Or you could build with pie disabled (but the .so's are pie), or run
with pie disabled; suggestion on StackOverflow to 'run under "setarch
x86_64 -R"', no idea whether that's useful.

Re: GNAT compiler versions and addr2line

[Phil]

Brian Drummond <brian@shapes.demon.co.uk> wrote:
> Basically Debian changed its policy (possibly for security reasons) 
> regarding Address Space Randomisation and position-independent 
> executables - not sure exactly what, perhaps they turned on PIE by 
> default, to allow address space randomisation. I've seen all those 5555s 
> in addresses so treated... (not so random, then?)

> Anyway, apparently addr2line doesn't work so well with random addresses...

> My "solution" is to suppress PIE, at least while debugging.

Adding -no-pie (gnatmake ... -largs -no-pie) means that addr2line works.
I'll have to look into the side-effects another time.

*Thank you*.

Phil.

Re: GNAT compiler versions and addr2line

[Phil]

Anh Vo <anhvofrcaus@gmail.com> wrote:
> On Wednesday, August 22, 2018 at 11:21:37 AM UTC-7, Phil wrote:
> > Alejandro R. Mosteo <alejandro@mosteo.com> wrote:
> > > I have seen the same up to current 7.3 FSF Ubuntu versions, and still 
> > > haven't found a workaround :/
> > 
> > Ah, at least it's not just me!

> gnatmake -g foo.adb -bargs -E for the following modified code. You
> will be pleasantly surprised that addr2line is not needed
> explicitly.

> with Gnat.Traceback.Symbolic;
> […]
>       Put_Line (GNAT.Traceback.Symbolic.Symbolic_Traceback(Err));
> end Foo;

Which compiler version, please?

Ironically, I started looking at addr2line when symbolic traceback
wasn't working (it had been my preferred method of dealing with
exceptions).  Digging in the adainclude directory, I eventually ended
up looking at s-trasym.adb.  The Debian FSF versions says

--  This is the default implementation for platforms where the full capability
--  is not supported. It returns tracebacks as lists of hexadecimal addresses
--  of the form "0x...".

and the implementation simply writes out the hex addresses.  The
current AdaCore community version has

--  Run-time symbolic traceback support for targets using DWARF debug data

and does work for symbolic traceback.  So with the FSF versions, I'd
still be using addr2line….

Phil.