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
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: GNAT compiler versions and addr2line
Date: Thu, 23 Aug 2018 18:21:26 +0100
Organization: A noiseless patient Spider
Message-ID: <lyd0u9m221.fsf@pushface.org>
References: <pljms6$jol$1@dont-email.me> <plkjfj$9ef$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org;
 posting-host="480c194f9f467224c5d983094c91cd25";
	logging-data="5099"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18j4vwpAy9H0UAUCBPTnbvVKHN4QMClJM8="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (darwin)
Cancel-Lock: sha1:00fX1LxK4KnumTDvjYCas5Bb1xo=
	sha1:8Wb7WIBNvys0Y8W4HcINZVW6nBU=
Xref: reader02.eternal-september.org comp.lang.ada:54230
Date: 2018-08-23T18:21:26+01:00
List-Id: <comp.lang.ada>

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.