[cfe-dev] debug_frame section not generated for Windows 64bit

Tue Apr 3 15:07:37 PDT 2018

Sorry, I missed this.

We don't have a solution to this, to the best of my knowledge. We just accept the loss of fidelity.

From: Reid Kleckner <rnk at google.com>
Date: Friday, March 23, 2018 at 11:10 AM
To: "jayvee.neumann at gmail.com" <jayvee.neumann at gmail.com>, Shoaib Meenai <smeenai at fb.com>
Cc: cfe-dev <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] debug_frame section not generated for Windows 64bit

Got it. I think the CFA is always the address of the return address, so such a DWARF consumer could be retrofitted to parse .xdata, find the caller's return address, and evaluate expressions using the CFA from there.

I don't think it's possible to get LLVM to emit DWARF CFI and Win CFI at the same time. The booleans in the prologue emission suggest that they are mutually exlusive:
  bool IsWin64Prologue = MF.getTarget().getMCAsmInfo()->usesWindowsCFI();
  ...
  bool NeedsDwarfCFI =
      !IsWin64Prologue && (MMI.hasDebugInfo() || Fn.needsUnwindTableEntry());

NeedsDwarfCFI controls the emission of the DWARF .cfi_* directives, which normally produce the .eh_frame or .debug_frame sections.

Shoaib, I think you have users of DWARF on Windows? How do they deal with this problem?

On Fri, Mar 23, 2018 at 12:06 AM Jayvee Neumann via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
Hi Reid,

your suggestion is not a solution to the problem I have. I still want to use SEH on 64bit Windows because it is, as you also pointed out, required by the ABI. I need a .debug_frame or .eh_frame section in addition to the SEH .pdata section. I am aware that the exception handling data would be redundant. Information about e.g. the CFA, which is required by some DWARF-expressions/locations, would not be redundant though.

Is there a way to request both, a .pdata section for SEH style exceptions and a .debug_frame sections, in the same or a similar way to MinGW-w64?

Best Regards
Jayvee

2018-03-23 0:22 GMT+01:00 Reid Kleckner <rnk at google.com<mailto:rnk at google.com>>:
Clang defaults to emitting SEH unwind information on Win64, since it is required by the ABI. DWARF EH tables would be redundant, but you can request them with -fdwarf-exceptions.

On Thu, Mar 22, 2018 at 4:05 PM Jayvee Neumann via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
Hi togehter,

I am currently switching from MinGW-w64 to clang. I am running into a problem with the debug information generated by clang, though. When building with mingw, there will always be an .eh_frame or a .debug_frame section. This is also true for 64bit windows. When I build the same files with clang for the target triple "x86_64-pc-windows-gnu" neither a .debug_frame nor an .eh_frame section is generated.

I there a way for me to explicitly specify via command line that such a section shall be generated?
If not, is there a way to change the llvm/clang source code in a way such that these sections will be generated for the specified target?

Best Regards,
Jayvee
_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=uoGEG5GL9LtEutiS6fDIgNRuS1OczWMVUMtgBL5cz6o&s=2dZrhCEkWh7IJ0k1oRknoTAqBFRRrMOT9rR8ZRuS2yc&e=>

_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=uoGEG5GL9LtEutiS6fDIgNRuS1OczWMVUMtgBL5cz6o&s=2dZrhCEkWh7IJ0k1oRknoTAqBFRRrMOT9rR8ZRuS2yc&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180403/dd8484b0/attachment.html>