Getting warning bad fde: FDE is really a CIE - GCC 6.3.1 extern "C"

[suedama1756]

Environment:

• Redhat Enterprise Server Linux Server release 7.6
• G++: 6.3.1 20170216 (Redhat 6.3.1-3)
• LLVM 9.0

I'm getting an "bad fde: FDE is really a CIE" warning when making calls to extern "C" functions in GCC 6.3.1. I can make the issue go away if I mark the external function with NoUnwind, however, I don't think this is the correct solution as the function may throw.

Taking a wild guess I tried setting the personality of the external function to __gxx_personality_v0 however this then fails validation as external functions cannot be given a personality.

I'm using LLVM 9.0 as a JIT, I'm using the ORC2 API, however, the issue is also demonstrable using the Kaleidascope JIT here: https://llvm.org/docs/tutorial/index.html The error is raised from the DwarfParser.hpp at the point the generated function is resolved (jitted)

Is there a correct way to deal with this, is it something I need to even worry about?

[dwblaikie]

you don't mention how any of this relates to clang/llvm - where is the error being produced from? where is llvm/clang used in this experiment?

[suedama1756]

you don't mention how any of this relates to clang/llvm - where is the error being produced from? where is llvm/clang used in this experiment?

I kind of figured it would be obvious to those that knew LLVM, however, in hindsight a little more information was probably required. Question updated...

[lhames]

At a minimum it’s usually helpful to provide your platform (Linux, Windows, Darwin, etc.), platform version, the LLVM version you are using and a little bit of context on what you were trying to do when you saw the error. Your update to the question helps a lot. Could you also include the platform you are running on?

Are you able to run this under a debugger and obtain a backtrace for the error? It’s coming from libunwind, so if you have the source for your LLVM build you should be able to grep it for “FDE is really a CIE” to find the line number to break on.

If this is happening in the JIT then my initial best guess is a bug in the eh-frame parsing / re-writing logic.

[suedama1756]

I've updated with version information. I do not have the full source for LLVM build I'm using, its a corporate box which I have limited access to so may take me a while to sort out. In the mean time do you have any ideas on a) are there any function attributes I can explicitly set other than nounwind that could help here. b) is this an issue I need to even care about?

[llvmbot]

@llvm/issue-subscribers-clang-codegen

[lhames]

Very belatedly: I think this is a common issue when using libunwind with JIT'd code on Linux. For a long time the JIT used "host-is-linux" as a proxy for "unwinder is libgcc_s". Since libgcc_s's implementation of __register_frame provided a fast-path if you registered the whole eh-frame section that's what we did. The problem happens when we call __register_frame this way and the unwinder is actually libunwind: The eh-frame section starts with a CIE, and it triggers this error.

@suedama1756 I think it is a problem -- we won't try to register the subsequent frames, so exceptions thrown through the JIT'd code will not behave correctly.

We're in the process of working through a fix for this: bab3981 added new functions to libunwind that have the behavior we want. We need to update the JIT to detect when these functions are available and use them. This will allow the JIT to work correctly with newer versions of libunwind. (Versions before bab3981 probably won't be fixed).

[lygstate]

Very belatedly: I think this is a common issue when using libunwind with JIT'd code on Linux. For a long time the JIT used "host-is-linux" as a proxy for "unwinder is libgcc_s". Since libgcc_s's implementation of __register_frame provided a fast-path if you registered the whole eh-frame section that's what we did. The problem happens when we call __register_frame this way and the unwinder is actually libunwind: The eh-frame section starts with a CIE, and it triggers this error.

@suedama1756 I think it is a problem -- we won't try to register the subsequent frames, so exceptions thrown through the JIT'd code will not behave correctly.

We're in the process of working through a fix for this: bab3981 added new functions to libunwind that have the behavior we want. We need to update the JIT to detect when these functions are available and use them. This will allow the JIT to work correctly with newer versions of libunwind. (Versions before bab3981 probably won't be fixed).

I think I also faced this issue, I am using mesa/llvmpipe that used llvm jit, and it's raised error:

libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE

What should I need to do to fixes this? #55584

[lhames]

@lygstate -- @housel committed fixes for libunwind (bab3981), and LLVM and the ORC runtime (981523b) that address this issue in the case where exceptions are registered via the ORC runtime.

You could use the ORC runtime in your JIT to fix this issue. We should also add checks for the new __unw_add_dynamic_eh_frame_section and __unw_remove_dynamic_eh_frame_section functions to the non-ORC-runtime registration paths.

[lhames]

I've filed #55681 to teach LLVM to use @housel's registration functions.