[llvm-bugs] [Bug 45324] New: Clang generates .debug_frame/.eh_frame with exceptions disabled for PE/COFF

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=45324

            Bug ID: 45324
           Summary: Clang generates .debug_frame/.eh_frame with exceptions
                    disabled for PE/COFF
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: vit9696 at avp.su
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

For any file (e.g. test.c as below) compiled into PE/COFF PDB debug information
and exceptions disabled (via -fno-exceptions) for i686, clang generates
.eh_frame / .debug_frame sections.

I believe this is undesired, as exceptions are explicitly disabled. My reasons
are:
- exceptions are not supported in UEFI in any case;
- we use PDB debug information, so DWARF exception info will not be handled
anyway;
- it is critical to have smaller file size in the firmware.

test.c:

void entry() {
}

$ clang -g -fno-builtin -ffunction-sections -fdata-sections -fno-common
-fno-stack-protector -funsigned-char -mno-implicit-float -nostdlib -nostdlibinc
-m32 -Oz -march=i586 -target i686-unknown-windows-gnu -gcodeview
-fno-exceptions -c -o test.obj test.c
$ lld-link /OUT:test.dll /NOLOGO /NODEFAULTLIB /IGNORE:4001 /OPT:REF
/OPT:ICF=10 /ALIGN:32 /FILEALIGN:32 /Machine:X86 /DLL /ENTRY:entry
/SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /BASE:0 /DEBUG:GHASH /SAFESEH:NO /lldmap
test.obj

The issue happens, because Clang Driver defines exception model regardless of
whether exceptions are disabled or not[1], and then AsmPrinter uncodintionally
uses the exception model to create a DwarfCFIException instance[2]. Then it is
emitted by emitFunctionHeader, which calls DwarfCFIException::beginFunction,
and eventually reaches MCAsmStreamer::EmitCFISections.

There is also a LLVM nuance here. In LLVM MCAsmInfo has Target-specific
defaults, which are set to DWARF[3] for 32-bit PE/COFF, and LLVMTargetMachine
will not override exception model to disabled[4]. This is likely because
exceptions are turned off for C code, however, on a non-freestanding
environment we probably still want to generate .eh_frame/.debug_info to
smoothly mix C and C++ code.

In my opinion, to properly resolve this issue we need to explicitly handle
-fno-exceptions in clang equally to other -fXXX-exceptions flags, forward it to
LLVM, and then handle it in LLVM as well. This is slightly unintuitive, because
of three states: as -fexceptions (some exception model), -fno-exceptions (none
exception model), and no argument (some exception model), but probably the
cleanest route.

[1]
https://github.com/llvm/llvm-project/blob/080d046c91d26bd3b0afba817cf5c2f99d1288ff/clang/lib/Driver/ToolChains/Clang.cpp#L5623-L5651
[2]
https://github.com/llvm/llvm-project/blob/fdfe411e7c9a844e7465bbe443fb6d1d9dbc4539/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp#L353-L378
[3]
https://github.com/llvm/llvm-project/blob/ee2c0f76d74cc03e54389926c9e626987e1408c3/llvm/lib/Target/X86/MCTargetDesc/X86MCAsmInfo.cpp#L162-L170
[4]
https://github.com/llvm/llvm-project/blob/b61a4aaca5f8a1e71eeaee74d93cdd6fccbef065/llvm/lib/CodeGen/LLVMTargetMachine.cpp#L70-L71

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200327/59f4524c/attachment.html>