Skip to content
Commit f10a3201 authored by Rui Ueyama's avatar Rui Ueyama
Browse files

COFF: Improve dllexported name mangling compatibility.

The rules for dllexported symbols are overly complicated due to
x86 name decoration, fuzzy symbol resolution, and the fact that
one symbol can be resolved by so many different names. The rules
are probably intended to be "intuitive", so that users don't have
to understand the name mangling schemes, but it seems that it can
lead to unintended symbol exports.

To make it clear what I'm trying to do with this patch, let me
write how the export rules are subtle and complicated.

 - x86 name decoration: If machine type is i386 and export name
   is given by a command line option, like /export:foo, the
   real symbol name the linker has to search for is _foo because
   all symbols are decorated with "_" prefixes. This doesn't happen
   on non-x86 machines. This automatic name decoration happens only
   when the name is not C++ mangled.

   However, the symbol name exported from DLLs are ones without "_"
   on all platforms.

   Moreover, if the option is given via .drectve section, no
   symbol decoration is done (the reason being that the .drectve
   section is created by a compiler and the compiler should always
   know the exact name of the symbol, I guess).

 - Fuzzy symbol resolution: In addition to x86 name decoration,
   the linker has to look for cdecl or C++ mangled symbols
   for a given /export. For example, it searches for not only
   _foo but also _foo@<number> or ??foo@... for /export:foo.

Previous implementation didn't get it right. I'm trying to make
it as compatible with MSVC linker as possible with this patch
however the rules are. The new code looks a bit messy to me, but
I don't think it can be simpler due to the ad-hoc-ness of the rules.

llvm-svn: 246424
parent e0a28e54
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment