[LLVMdev] So what's the deal with debug_frame V eh_frame

[David Blaikie]

On Thu, Mar 20, 2014 at 10:41 AM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
> On 19 March 2014 17:31, David Blaikie <dblaikie at gmail.com> wrote:
>> While comparing debug info between GCC and Clang I found a section
>> that only Clang produces and GCC never produces: debug_frame.
>>
>> It seems (though I haven't verified this with absolute certainty) as
>> though GCC just always uses eh_frame. LLVM on the other hand sometimes
>> uses eh_frame and sometimes uses debug_frame.
>>
>> Here's an example:
>>
>> int f1();
>> int i = f1();
>> void func() { }
>>
>> Compiled with -fno-exceptions -g.
>>
>> The first two lines produce a global ctor.
>>
>> Clang is generous enough to flag the LLVM IR function for this global
>> ctor ("__cxx_global_var_init") as nounwind
>> (tools/clang/lib/CodeGen/CGDeclCXX.cpp:246), though "func" gets
>> flagged as nounwind but also as uwtable (why? I don't really
>> understand these semantics & haven't tracked down where that attribute
>> gets applied)
>
> Is this x86-64? If so, uwtable is a abi requirement. It says that that
> function should have an entry in .eh_table.

Hmm, OK then - because I've certainly seen LLVM emit object files with
no eh_frame (as in the above example, if "func" is omitted).

>
>> Without 'func' in this translation unit, LLVM emits a debug_frame
>> section (because no functions actually need an unwind table, but we're
>> compiling with debug info (without debug info LLVM emits no _frame
>> section at all)). With 'func', LLVM switches to emitting an eh_frame
>> section in both (-g and no -g) cases.
>>
>> GCC on the other hand emits eh_frame in all 4 cases (with and without
>> -g and with and without 'func' defined).
>>
>> Do we need all this logic? Should we just always use eh_frame? Should
>> we not have the 'uwtable' attribute on 'func'? Why is 'func' different
>> from the global ctor in this regard?
>
> .debug_frame is a non-load section. It is therefore an optimization to
> emit it instead of .eh_frame. It is very likely not really a relevant
> one, so it might be possible to just always use .eh_frame.
>
> Not adding uwtable for _GLOBAL__I_a might actually be a bug. I will
> check what gcc does.

In my experiments GCC /always/ produced eh_frame, never debug_frame, fwiw.