Unmapped DWARF Register #63 encountered

[qn2000]

We compile our library with the following flags:
-nodefaultlibs -shared -shared-libgcc -Wl,Bsymbolic

For the debug build we also use -g -O0 -DDEBUG. For release build, we add -O2 -Wuniniitialized

The debug build works fine. However, the release build crashes at some point after it's run. I tried adding the -g flag to the release build and ran in inside of gdb. When the crash occurred, it showed the following messages:

Unmapped DWARF Register #63 encountered
Unmapped DWARF Register #63 encountered
...

The backtrace shows only 2 calls and it looks af ifwe're having a corrupt stack.

I then tried the release build with -O0 option and it worked fine. Is there a problem with -O2 with Intel C/C++ version 11 for Linux? I noticed there is the -opt-prefetch-initial-values option which sounds interesting. We've been using version 9 all these years, and now we're upgrading it to version 11.

Any suggestions?

Thanks...

[qn2000]

Quoting - qn2000

We compile our library with the following flags:
-nodefaultlibs -shared -shared-libgcc -Wl,Bsymbolic

For the debug build we also use -g -O0 -DDEBUG. For release build, we add -O2 -Wuniniitialized

The debug build works fine. However, the release build crashes at some point after it's run. I tried adding the -g flag to the release build and ran in inside of gdb. When the crash occurred, it showed the following messages:

Unmapped DWARF Register #63 encountered
Unmapped DWARF Register #63 encountered
...

The backtrace shows only 2 calls and it looks af ifwe're having a corrupt stack.

I then tried the release build with -O0 option and it worked fine. Is there a problem with -O2 with Intel C/C++ version 11 for Linux? I noticed there is the -opt-prefetch-initial-values option which sounds interesting. We've been using version 9 all these years, and now we're upgrading it to version 11.

Any suggestions?

Thanks...

By the way, this only happens on 64bit with -O2 option. It does not happen on 32bit, release or debug.

[qn2000]

Quoting - qn2000

By the way, this only happens on 64bit with -O2 option. It does not happen on 32bit, release or debug.

I just did a rebuild with -O1 instead of -O2 and it worked fine. Hmmm...

[qn2000]

Quoting - qn2000

I just did a rebuild with -O1 instead of -O2 and it worked fine. Hmmm...

Any ideas what might be wrong? Any suggestions I can try, like which flags I can try along with -O2?

[DAVID_M_Intel2]

Quoting - qn2000

Any ideas what might be wrong? Any suggestions I can try, like which flags I can try along with -O2?

I have not seen that message before. It would suggest a problem in an FDE or CIE, ata guess. If you can create a reproducer that you are able to send to us, I would like to take a look.

You could try -f[no-]omit-frame-pointer. (In the no-version of course). Thatwill probably help with the stack walkback. It may or may not change the behavior of your program - probably it won't - but it could make it more debuggable.

However, debugging at O2 has to be done with care. The optimized code can be a long way from being easily mappable back to your source code. So you won't always be able to see a variable. There's an option "-debug extended" that causes more detailed debug output for variables to be output that you may find useful.

BTW, are you remembering to say -fpic on all your compiles for objects that go into your shared library? If you are including a static library, for example, into your shared library,that needs to be -fpic'd as well. I don't think -shared implies -fpic on the command line. You probably would get an error message from the linker on Intel 64 if you forgot this,but perhaps its possible to not get that and to run into runtime trouble instead. The FDE and CIE formats change with -fpic too, although I don't think that should result in an error like the one you report.

Sorry I cannot be of more help.

[qn2000]

Quoting - David Moore (Intel)

I have not seen that message before. It would suggest a problem in an FDE or CIE, ata guess. If you can create a reproducer that you are able to send to us, I would like to take a look.

You could try -f[no-]omit-frame-pointer. (In the no-version of course). Thatwill probably help with the stack walkback. It may or may not change the behavior of your program - probably it won't - but it could make it more debuggable.

However, debugging at O2 has to be done with care. The optimized code can be a long way from being easily mappable back to your source code. So you won't always be able to see a variable. There's an option "-debug extended" that causes more detailed debug output for variables to be output that you may find useful.

BTW, are you remembering to say -fpic on all your compiles for objects that go into your shared library? If you are including a static library, for example, into your shared library,that needs to be -fpic'd as well. I don't think -shared implies -fpic on the command line. You probably would get an error message from the linker on Intel 64 if you forgot this,but perhaps its possible to not get that and to run into runtime trouble instead. The FDE and CIE formats change with -fpic too, although I don't think that should result in an error like the one you report.

Sorry I cannot be of more help.

The flags we use for compiling the shared libs are:
-c
-D_REENTRANT
-D_LARGE_INTEGER
-D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64
-DDEBUG -D_DEBUG (only for debug build)
-fPIC
-pch
-no-vec
-Qoption,cpp,--no_pch_messages
-pch_dir
-Wreturn-type
-Wno-deprecated
-fpack-struct (we also tried without this)
-O2
-Wuninitialized
-g (for debug symbols)


Flags for linking:
-nodefaultlibs (with or without this the crash still occurs)
-shared
-shared-libgcc
-Wl,-Bsymbolic


For kicks, I also tried the -dryrun flag to see the differences between -O2 and -O1. The outout of -O1 has the following info that -O2 doesn't:
-D__OPTIMIZE_SIZE__
-mGLOB_nonstandard_lib
-mGLOB_opt_for_size=100
-mP2OPT_lur=FALSE
-mP2OPT_hlo_loop_unroll=FALSE
-mP2OPT_unroll_amount_ceiling=0

[Om_S_Intel]

Quoting - qn2000

I'm not sure if we could come up with a standalone testcase program given the condition and time it takes for the crash to occur. :( I'll check out your suggestion. Thanks.

This issue seem to be fixed in Intel C++ compiler 11.0.083.

[Om_S_Intel]

The issue is fixed in latest Intel C++ compiler. The compiler is available for download from registration center https://registrationcenter.intel.com/.