[llvm-bugs] [Bug 27424] New: .pdata sections for associative comdat functions are rejected by MSVC 2015 incremental linker

[via llvm-bugs]

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

            Bug ID: 27424
           Summary: .pdata sections for associative comdat functions are
                    rejected by MSVC 2015 incremental linker
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: MC
          Assignee: unassignedbugs at nondot.org
          Reporter: rnk at google.com
                CC: david.majnemer at gmail.com, llvm-bugs at lists.llvm.org,
                    nicolasweber at gmx.de, rafael.espindola at gmail.com
    Classification: Unclassified

This was encountered in Chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=595702

A C test case:
void f();
int main() {
  __try {
    f();
  } __finally {
    f();
  }
}

Given this code, clang will produce two .text sections: one for main and one
for the finally funclet. The finally funclet is COMDAT associative with the
main .text section. Our COFF section uniquing table is keyed on section name,
comdat selection type, and associative comdat symbol. When we go to create
.pdata sections for those .text sections, we end up reusing the same .pdata
section for both.

In a non-incremental linking scenario, this appears to be OK: the .text and
.pdata sections will all be included in or discarded from the executable
together. However, when linking incrementally, the new 2015 linker appears to
expect each .pdata section to only contain relocations against a single .text
section, i.e. there is a one-to-one mapping from .pdata section to .text
section. LLVM doesn't currently do that.

Here's a reduced LLVM IR test case that we should presumably emit two .pdata
sections for but don't today:

$f = comdat any
define weak_odr void @f() comdat($f) {
  call void @g()
  ret void
}
define internal void @g() comdat($f) {
  ret void
}

How should we solve this? We could implement support for .section ...,unique,ID
like we have for ELF, and then teach MC to use this functionality to implement
.seh_handlerdata. However, all that assembler support is totally unnecessary
for the problem at hand, because .pdata is emitted late by the .seh_handlerdata
directive.

It's also worth pointing out that C++ EH funclets currently do not use separate
.text sections, and in that case we should have one .pdata and .xdata section
with an entry for each funclet. If we bypassed the uniquing map and directly
created a new .pdata section every time we need it, we will end up with more
sections than we need in this case.

-- 
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/20160419/e32033c5/attachment.html>