Re: [Libunwind-devel] Libunwind reports the same ip and fp for Fortran code compiled with PGI

[Scott Biersdorff]

Thanks, adding this worked great on Linux, Do you know the equivalent section 
in a Mach-O binary (OSX) that needs to be present for libunwind to get the 
correct IP and FP (eh_frame_hdr does not appear to be present for gnu compiled 
binaries)?

- Scott

-----Original Message-----
From: Chris January [mailto:address@hidden 
Sent: Tuesday, January 20, 2015 1:45 AM
To: Scott Biersdorff
Cc: address@hidden; Juul VanderSpek
Subject: Re: [Libunwind-devel] Libunwind reports the same ip and fp for Fortran 
code compiled with PGI

Hello Scott,

The PGI compiled executable is missing the .eh_frame_hdr section. Try adding 
-Wl,--eh-frame-hdr to LDFLAGS in Makefile. This fixes the problem.

Regards,
Chris January - VP Engineering - Allinea Software Ltd.

On Mon, 2015-01-19 at 22:02 +0000, Scott Biersdorff wrote:
> We are looking into an issue with libunwind where it reports the same 
> address as both a IP and FP. This happens with a simple PGI compiled 
> Fortran example. This same example compiled with gfortran reports 
> different addresses:
> 
>  
> 
> ./fortran-standalone.gnu.exe
> 
>  ip= 0x0000000000400b19  fp= 0x0000000000400aff
> 
>  ip= 0x0000000000400a45  fp= 0x000000000040098d
> 
>  ip= 0x0000000000400aa4  fp= 0x0000000000400a82
> 
>  ip= 0x0000000000400af8  fp= 0x0000000000400ac4
> 
>  ip= 0x00007f43bad53ec5  fp= 0x00007f43bad53dd0
> 
>  ip= 0x00000000004008c9  fp= 0x00000000004008a0
> 
>  
> 
> ./fortran-standalone.pgi.exe
> 
>  ip= 0x00000000004027eb  fp= 0x00000000004027eb
> 
>  ip= 0x00000000004027b0  fp= 0x00000000004027b0
> 
>  ip= 0x0000000000402712  fp= 0x0000000000402712
> 
>  ip= 0x00000000004026c4  fp= 0x00000000004026c4
> 
>  
> 
> (Note that both stacks run into strange addresses unknown in the 
> object file; my suspicion is that these are trampoline functions 
> somewhere on stack or heap).
> 
>  
> 
> I’ve attached the sources and binaries for this example. Can you help 
> us understand what is particular about this binary compiled by PGI 
> that causes this? Is there another way to retrieve the function 
> pointer?