[llvm-bugs] [Bug 28699] New: RTDyldMemoryManager::getSymbolAddressInProcess not working on Windows

[via llvm-bugs]

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

            Bug ID: 28699
           Summary: RTDyldMemoryManager::getSymbolAddressInProcess not
                    working on Windows
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: j4_james at hotmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Originally the RTDyldMemoryManager::getSymbolAddressInProcess method included
code that demangled the symbol name (i.e. removed the underscore prefix) on all
platforms, but that behaviour was changed in revision 262657 so it's now only
applied on the __APPLE__ platform. This change seems to have caused the method
to fail on Windows.

For example, when testing the BrainF example app, I was able to get a sample
helloworld script to compile to bitcode, but when I tried to execute that
bitcode with the lli interpreter, it produced the error:

LLVM ERROR: Program used external function '_free' which could not be resolved!

Once I updated the code that strips the underscore so that it was applied on
both the __APPLE__ and _WIN32 platforms, the interpreter was then able to
execute the bitcode successfully.

That said, I'm not sure that's necessarily the correct solution. Is it possible
there may be cases where the name genuinely does need to be left with the
underscore intact on Windows? The original code tried to lookup the name both
with and without the prefix, which may be the safer option.

In case it makes any difference, I'm testing with Visual Studio 2015 Community
Edition on Windows 10 and the LLVM suite was built from trunk (currently
revision 276679) with cmake -G "Visual Studio 14 2015"

-- 
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/20160725/2c856ea8/attachment.html>