[llvm-dev] Generating debug information with OpenMP enabled

[Rob Lyerly via llvm-dev]

Hi all,

I'm compiling a C/OpenMP application with clang/LLVM v 3.7.1 on aarch64
("-target aarch64-linux-gnu").  I'm also compiling with "-g" and
"-gdwarf-aranges" to get debugging information for my application.  For
most source code files (i.e. ones without OpenMP pragmas), the compiler
puts frame description entries (FDEs) in the ".debug_frame" section of my
executable.  The output from readelf looks pretty sane (in particular, the
address ranges look correct):

$ readelf --debug-dump=frames-interp <my bin>

Contents of the .debug_frame section:

00000000 0000000000000014 ffffffff CIE "" cf=1 df=-4 ra=30
   LOC           CFA
0000000000000000 r31+0

00000018 0000000000000024 00000000 FDE cie=00000000
*pc=0000000000410000..0000000000410238*
   LOC           CFA      r19   r20   r21   r22   r29   ra
0000000000410000 r31+0    u     u     u     u     u     u
0000000000410014 r29+16   c-24  c-32  c-40  c-48  c-16  c-8
...

However for the source code file with OpenMP pragmas, the compiler puts
frame descriptor entries in the ".eh_frame" section.  I'm assuming this is
because LLVM's OpenMP runtime is compiled using C++ and therefore needs
asynchronous unwind tables.  Not a problem, but it's populating the address
ranges with (seemingly) bad values:

Contents of the .eh_frame section:

00000000 0000000000000014 00000000 CIE "zR" cf=1 df=-4 ra=30
   LOC           CFA
0000000000000000 r31+0

00000018 000000000000001c 0000001c FDE cie=00000000
*pc=ffffffffe0594070..ffffffffe05940ac*
   LOC           CFA      r29   ra
ffffffffe0594070 r31+0    u     u
ffffffffe059407c r29+16   c-16  c-8
...

Is this a bug, or are those address ranges correct?  How am I supposed to
be interpreting those?  Note that I don't have code anywhere near that
address range in my binary.  Thanks!

-- 
Rob Lyerly
Graduate Research Assistant, Systems Software Research Group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160426/eb460e5b/attachment.html>