[llvm-bugs] [Bug 35625] New: Wasm backend: crash on address of aliased function name

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Dec 11 08:11:34 PST 2017


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

            Bug ID: 35625
           Summary: Wasm backend: crash on address of aliased function
                    name
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: WebAssembly
          Assignee: unassignedbugs at nondot.org
          Reporter: ncw at realvnc.com
                CC: llvm-bugs at lists.llvm.org

Discovered while prodding the libcxx build along a bit further...


Compiling the following equivalent test-cases causes an assertion failure, in
WasmObjectWriter::getRelocationIndexValue, with the message "symbol not found
table index space".

==== Test file
void exportedFn(void) {}

extern void aliasFn() __attribute__((alias("exportedFn")));

int takePtr() { return (int)&aliasFn; }
====

The symbol "aliasFn" is not added to IndirectSymbolIndices, even though
IsAddressTaken returns true for it, because WS.isVariable() is true (it's an
MCExpr::SymbolRef).  Later on, the relocation attempts to reference the table
index for aliasFn, but no index was assigned because we skipped processing for
it.


The following (extremely common) C++ code will trigger the same bug:

==== C++ testcase
class CtorClass {
public:
    CtorClass();
    ~CtorClass();
};

CtorClass::CtorClass() {}

CtorClass::~CtorClass() {}

CtorClass createObject() { return CtorClass(); }
====

The problem is the same here. C++ codegen creates two functions,
"_ZN9CtorClassC2Ev" and "_ZN9CtorClassC1Ev", the latter of which is an alias of
the former.  Hence, we have the same crash because a relocation is generated
against the aliased constructor.

(Oddly, I can't quite see why the address is taken in this case? When running
with "clang -emit-llvm" followed by "llc", the C++ case compiles fine! And
there's no address-of in the emitted bitcode.)

-- 
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/20171211/5e5d347f/attachment-0001.html>


More information about the llvm-bugs mailing list