[PATCH] D19376: [MC] Create unique .pdata sections for every .text section

[Reid Kleckner via llvm-commits]

rnk added a comment.

Thanks for the input, I'll try moving this to MCWinCOFFStreamer.


================
Comment at: include/llvm/CodeGen/TargetLoweringObjectFileImpl.h:135
@@ -134,1 +134,3 @@
 class TargetLoweringObjectFileCOFF : public TargetLoweringObjectFile {
+  mutable unsigned NextUniqueID = 1;
+
----------------
rafael wrote:
> Why start with 1? Not that it is really important, but ELF start with 0.
What is the generic unique ID for ELF? What unique ID do I get if I write `.text`?

I assumed it was zero, but if it's ~0U, then sure I can start this at zero.

================
Comment at: include/llvm/MC/MCContext.h:91
@@ +90,3 @@
+    unsigned NextTextSectionID = 1;
+    DenseMap<const MCSection *, unsigned> TextSectionIDs;
+
----------------
rafael wrote:
> Can't this just be a field in MCSectionCOFF like it is for ELF?
This should have more comments. It exists to map from text section to the unique id of its corresponding pdata section, so that if a text section contains more than one function using SEH, we can reuse the same pdata section for it. This matters for C++ funclets, which should also have a test.

================
Comment at: include/llvm/MC/MCContext.h:410
@@ +409,3 @@
+    /// section, but it may be any section containing code.
+    MCSection *getPDataSectionForTextSection(const MCSection *TextSec);
+
----------------
rafael wrote:
> Can you move this out of the context? It looks similar to ELF relocation sections. We handle that mapping in the elf writer and we only createELFRelSection in the context.
IIUC, ELF relocation sections are below the abstraction level of the assembler. They're something created automatically based on your symbol references.

While we could push .pdata down to that level, the .xdata section is not below that level. The user needs to be able to put their LSDA there. It is a real section opened up by .seh_handlerdata that can be pushed and popped.

I could maintain this mapping in MCWinCOFFStreamer, though, and that would be close to what you're thinking of?

Another twist is that lib/CodeGen/AsmPrinter/WinException.cpp needs to switch to the .xdata section. On 32-bit x86, it doesn't use the .seh_handlerdata directive to do it. Should I have getXDataSectionForTextSection be a method of MCStreamer, or have WinException downcast the MCStreamer to an MCWinCOFFStreamer?


http://reviews.llvm.org/D19376