[LLD] [COFF] Use the unified llvm demangle frontend function. NFC.

[mstorsjo]

Summary

This isn't a strict NFC patch, as technically, as symbols starting with __Z also could be demangled now. As the namespace starting with two underscores is restricted to the platform implementation in at least C, this shouldn't be much of an issue in practice.

[rnk]

Should the _ prefix (for itanium symbols in i386 mode) be stripped by the COFF wrapper function, or by the common demangle function (matching _Z or __Z)?

Maybe, I forget if the extra _ comes before the __imp_ prefix or after it when dllimported. But there's another consideration, which is that this code could hypothetically be shared with a MachO linker implementation, where the extra underscore prefix is also present. IMO it's best for any generic demangler to match any number of underscores followed by Z.

[rnk]

Hit send too soon...

Or did you mean merging the two demangler functions at the llvm level as well?

I'd be in favor of doing that as well, if it's easy. :)

[mstorsjo]

In D67301#1661748, @rnk wrote:

Should the _ prefix (for itanium symbols in i386 mode) be stripped by the COFF wrapper function, or by the common demangle function (matching _Z or __Z)?

Maybe, I forget if the extra _ comes before the __imp_ prefix or after it when dllimported.

It's after the __imp_ prefix, so the demangler could handle it.

But there's another consideration, which is that this code could hypothetically be shared with a MachO linker implementation, where the extra underscore prefix is also present. IMO it's best for any generic demangler to match any number of underscores followed by Z.

I'm not entirely decided on whether I think this is a good thing or not.

The caller knows with certainty whether there should be an extra underscore prefix or not, as it is well defined (always in MachO, never in ELF, plus on i386 in COFF). But if we make the demangler implicitly handle both cases, it can also accidentally e.g. try to demangle any symbol which just starts with a capital Z, without any real underscore prefix, on i386 in COFF or in MachO. (I realize the current code in LLD I just committed also has this issue though.) So if we make it a requirement for the caller to compensate for the prefix, it is less convenient, but also less ambiguous.

WDYT?

[ruiu]

Merging the demanglers for Itanium and MSVC seems fine at the lld level because we handle only these two mangling schemes. But isn't there any mangling scheme than those two? Can all mangling schemes be distinguished reliably? If not, we can't provide a unified demangle function.

As to the underscore prefix, I prefer making it a caller's responsibility to strip it before calling a demangler. As you mentioned, callers always know which is the case.

[mstorsjo]

In D67301#1662223, @mstorsjo wrote:

But if we make the demangler implicitly handle both cases, it can also accidentally e.g. try to demangle any symbol which just starts with a capital Z, without any real underscore prefix, on i386 in COFF or in MachO. (I realize the current code in LLD I just committed also has this issue though.)

Just for the record, correcting myself here, no, that can't happen as the code stands right now after all. On i386, a leading underscore is consumed if present before calling the demangler.

[rnk]

In D67301#1662223, @mstorsjo wrote:

In D67301#1661748, @rnk wrote:

Should the _ prefix (for itanium symbols in i386 mode) be stripped by the COFF wrapper function, or by the common demangle function (matching _Z or __Z)?

Maybe, I forget if the extra _ comes before the __imp_ prefix or after it when dllimported.

It's after the __imp_ prefix, so the demangler could handle it.

But there's another consideration, which is that this code could hypothetically be shared with a MachO linker implementation, where the extra underscore prefix is also present. IMO it's best for any generic demangler to match any number of underscores followed by Z.

I'm not entirely decided on whether I think this is a good thing or not.

The caller knows with certainty whether there should be an extra underscore prefix or not, as it is well defined (always in MachO, never in ELF, plus on i386 in COFF). But if we make the demangler implicitly handle both cases, it can also accidentally e.g. try to demangle any symbol which just starts with a capital Z, without any real underscore prefix, on i386 in COFF or in MachO. (I realize the current code in LLD I just committed also has this issue though.) So if we make it a requirement for the caller to compensate for the prefix, it is less convenient, but also less ambiguous.

WDYT?

I would hope that demangling a non-C++ symbol that happens to start with Z would simply fail and return the original string. In practice, we have tools like demumble that work on text streams and look for any sequence of _+Z${alphanum}+ and they work well enough. But I don't feel strongly, I see the argument for safety.

[mstorsjo]

It turns out most of this discussion already is moot; the llvm demangle library already has a common unified function, which takes itanium names with 1-4 leading underscores. That makes this patch even simpler, mostly just rip out a lot of duplicated code from lld. This makes things a bit looser (the previous lld frontend to itaniumDemangle required it to start with exactly _Z), but as this is the current behaviour of the common demangle library, that's probably not an issue in practice.

[mstorsjo]

Updated to use the already unified llvm demangler frontend function, removing a lot of duplicated code in lld.

I'm adding another entry point to it, Optional<std::string> tryDemangle(const std::string &MangledName), that easier allows distinguishing between whether it actually did demangle or not, used in the COFF code.

[MaskRay]

This change is not NFC. This will cause every port of LLD to demangle more names than which were allowed before.

tryDemangle can decode more names than _Z __Z ___Z ____Z prefixed names, as can be seen from the source:

// <mangled-name> ::= _Z <encoding>
//                ::= <type>
// extension      ::= ___Z <encoding> _block_invoke
// extension      ::= ___Z <encoding> _block_invoke<decimal-digit>+
// extension      ::= ___Z <encoding> _block_invoke_<decimal-digit>+
template <typename Derived, typename Alloc>
Node *AbstractManglingParser<Derived, Alloc>::parse() {

I hope at least for ELF, you can keep the "_Z" prefix check. It doesn't need the ObjC "___Z" extension.

[mstorsjo]

In D67301#1664700, @MaskRay wrote:

This change is not NFC. This will cause every port of LLD to demangle more names than which were allowed before.

I hope at least for ELF, you can keep the "_Z" prefix check. It doesn't need the ObjC "___Z" extension.

Ok, let's keep it strict then.

I'd suggest adding a parameter to the llvm global demangle convenience function, to decide between whether it should require a strict prefix (only _Z) or if 1-4 underscores are allowed.

[mstorsjo]

Extended the llvm demangle function to take an optional parameter for requesting it to only demangle symbols with a stricter prefix check (only allowing _Z).

Added test cases in lld for cases where we don't want demangling to happen (which all pass in the current master as well).

[rnk]

In D67301#1664700, @MaskRay wrote:

I hope at least for ELF, you can keep the "_Z" prefix check. It doesn't need the ObjC "___Z" extension.

Are you sure? Surely users could use -fblocks to get those manglings, or use ObjC on Linux.

[MaskRay]

In D67301#1665171, @rnk wrote:

In D67301#1664700, @MaskRay wrote:

I hope at least for ELF, you can keep the "_Z" prefix check. It doesn't need the ObjC "___Z" extension.

Are you sure? Surely users could use -fblocks to get those manglings, or use ObjC on Linux.

We haven't even heard people complaining about lack of demangling of __Z, ___Z or ___Z prefixed names. I still lean towards keeping the "_Z" check for ELF to avoid false positive.

llvm/include/llvm/Demangle/Demangle.h

12 ↗

(On Diff #219584)

I'm not sure this is supported.

LLVMSupport depends on LLVMDemangle. LLVMDemangle probably shouldn't have any dependency on other components.

[mstorsjo]

llvm/include/llvm/Demangle/Demangle.h

12 ↗

(On Diff #219584)

Hmm, good point.

I can do without the Optional here then, that form is only used in one place anyway.

[mstorsjo]

Removed use of llvm::Optional in the demangle library, adapted COFF/Symbols.cpp to do a check for "demangled != demangleInput" instead of checking an Optional return value.

[sbc100]

lld/COFF/Symbols.cpp

38

I think the convention is to use /*StrictPrefix=*/true. i.e. no spaces and an equals.

lld/wasm/Symbols.cpp

303 ↗

(On Diff #219661)

Haven't we lost the checking of config->demangle here?

[mstorsjo]

lld/COFF/Symbols.cpp

38

Ok, will change all of them to that form

lld/wasm/Symbols.cpp

303 ↗

(On Diff #219661)

Oops, yes indeed. (There wasn't any testcase for that, apparently.)

[mstorsjo]

lld/wasm/Symbols.cpp

303 ↗

(On Diff #219661)

Sorry, yes, there is a test for it, but I don't have the wasm target enabled, so that particular test doesn't get run.

[mstorsjo]

Tweaked the syntax for parameter literal names in comments, reinstated a check for config->demangle in the wasm backend.

[mstorsjo]

In D67301#1665612, @MaskRay wrote:

In D67301#1665171, @rnk wrote:

In D67301#1664700, @MaskRay wrote:

I hope at least for ELF, you can keep the "_Z" prefix check. It doesn't need the ObjC "___Z" extension.

Are you sure? Surely users could use -fblocks to get those manglings, or use ObjC on Linux.

We haven't even heard people complaining about lack of demangling of __Z, ___Z or ___Z prefixed names. I still lean towards keeping the "_Z" check for ELF to avoid false positive.

@rnk - do you want to follow up on this further, or should we move forward with this in this form (which is pretty much NFC now).

[mstorsjo]

In D67301#1668327, @mstorsjo wrote:

In D67301#1665612, @MaskRay wrote:

In D67301#1665171, @rnk wrote:

In D67301#1664700, @MaskRay wrote:

I hope at least for ELF, you can keep the "_Z" prefix check. It doesn't need the ObjC "___Z" extension.

Are you sure? Surely users could use -fblocks to get those manglings, or use ObjC on Linux.

We haven't even heard people complaining about lack of demangling of __Z, ___Z or ___Z prefixed names. I still lean towards keeping the "_Z" check for ELF to avoid false positive.

@rnk - do you want to follow up on this further, or should we move forward with this in this form (which is pretty much NFC now).

Ping @rnk

[ruiu]

lld/COFF/Symbols.cpp

39–40

Does this mean __imp_foo is printed as just __imp_foo but any C++ mangled name after __imp_ is printed as __declspec(dllimport) ...? It feels to me that always "demangle" __imp prefix is more consistent.

[mstorsjo]

lld/COFF/Symbols.cpp

39–40

Yes, that's correct - that's how it's done right now.

Sure, we could change that, but that would be a separate change, as this tries to be an NFC refactoring.

[rnk]

In D67301#1665612, @MaskRay wrote:

We haven't even heard people complaining about lack of demangling of __Z, ___Z or ___Z prefixed names. I still lean towards keeping the "_Z" check for ELF to avoid false positive.

Weighing this desire to not change functionality against the cost of adding an extra boolean default argument to control the behavior, I'd prefer to change behavior to be consistent everywhere.

I guess we can't predict which bug is more likely: failing to demangle something the user wanted us to demangle, or unintentionally demangling a real C symbol starting with Z. Regardless of which bug appears down the road, I favor the solution that takes less code and makes LLVM tools behave consistently.

[MaskRay]

In D67301#1680905, @rnk wrote:

In D67301#1665612, @MaskRay wrote:

We haven't even heard people complaining about lack of demangling of __Z, ___Z or ___Z prefixed names. I still lean towards keeping the "_Z" check for ELF to avoid false positive.

Weighing this desire to not change functionality against the cost of adding an extra boolean default argument to control the behavior, I'd prefer to change behavior to be consistent everywhere.

I guess we can't predict which bug is more likely: failing to demangle something the user wanted us to demangle, or unintentionally demangling a real C symbol starting with Z. Regardless of which bug appears down the road, I favor the solution that takes less code and makes LLVM tools behave consistently.

Is there a scenario where both Itanium and Microsoft mangling schemes should be tried? (mingw?) If no, separate entry points for itaniumDemangle and microsoftDemangle may be better. I did not expect the solution to end up with an extra parameter StrictPrefix. The additional complexity was not what I intended. If mingw has to live with both mangling schemes, I want to first check if the demangling code will be used in more than one places. If yes, I am not against deleting StrictPrefix. The overhead to demangle __Z, ___Z or ___Z prefixed names for ELF should be small.

[mstorsjo]

In D67301#1681906, @MaskRay wrote:

In D67301#1680905, @rnk wrote:

In D67301#1665612, @MaskRay wrote:

We haven't even heard people complaining about lack of demangling of __Z, ___Z or ___Z prefixed names. I still lean towards keeping the "_Z" check for ELF to avoid false positive.

Weighing this desire to not change functionality against the cost of adding an extra boolean default argument to control the behavior, I'd prefer to change behavior to be consistent everywhere.

I guess we can't predict which bug is more likely: failing to demangle something the user wanted us to demangle, or unintentionally demangling a real C symbol starting with Z. Regardless of which bug appears down the road, I favor the solution that takes less code and makes LLVM tools behave consistently.

Is there a scenario where both Itanium and Microsoft mangling schemes should be tried? (mingw?)

No, practically, only one of them should be possible at a given time. But I don't see why that is relevant to the discussion at hand.

If no, separate entry points for itaniumDemangle and microsoftDemangle may be better.

The distinction between itanium and microsoft isn't an issue here, at all.

They have strictly very different mangling; microsoft mangled names start with a ? while itanium mangled ones start with _Z. There is no risk of mixing them up at all.

On i386, all symbols (except for microsoft mangled and certain other calling conventions) start with an extra underscore, so itanium mangled names start with __Z. This is currently handled by always manually stripping one underscore on i386 before calling the demangler, but could be skipped as well if we use a more tolerant demangler. It could also be kept to avoid the risk of demangling a symbol like Znwy that originally didn't start with an underscore.

I did not expect the solution to end up with an extra parameter StrictPrefix. The additional complexity was not what I intended. If mingw has to live with both mangling schemes, I want to first check if the demangling code will be used in more than one places. If yes, I am not against deleting StrictPrefix. The overhead to demangle __Z, ___Z or ___Z prefixed names for ELF should be small.

It's not at all about the two different mangling schemes.

It's only about whether we artifically should make the general itanium demangler routine more strict than it is right now, or accept that there's a small risk of demangling something that isn't supposed to, but this is already a risk that all existing callers of the general llvm demangle library are ok with.

[MaskRay]

In D67301#1681928, @mstorsjo wrote:

In D67301#1681906, @MaskRay wrote:

In D67301#1680905, @rnk wrote:

In D67301#1665612, @MaskRay wrote:

We haven't even heard people complaining about lack of demangling of __Z, ___Z or ___Z prefixed names. I still lean towards keeping the "_Z" check for ELF to avoid false positive.

Weighing this desire to not change functionality against the cost of adding an extra boolean default argument to control the behavior, I'd prefer to change behavior to be consistent everywhere.

I guess we can't predict which bug is more likely: failing to demangle something the user wanted us to demangle, or unintentionally demangling a real C symbol starting with Z. Regardless of which bug appears down the road, I favor the solution that takes less code and makes LLVM tools behave consistently.

Is there a scenario where both Itanium and Microsoft mangling schemes should be tried? (mingw?)

No, practically, only one of them should be possible at a given time. But I don't see why that is relevant to the discussion at hand.

If a call site of llvm::demangle deals either exclusively Itanium mangled names, or exclusively MSVC-style mangled names. I don't see why we must have a single entry point (llvm::demangle) for demangling. Two entry points (for Itanium and MSVC-style) may be better. It avoids the problem that some platforms are unnecessarily affected by special rules from some particular platforms.

If no, separate entry points for itaniumDemangle and microsoftDemangle may be better.

The distinction between itanium and microsoft isn't an issue here, at all.

They have strictly very different mangling; microsoft mangled names start with a ? while itanium mangled ones start with _Z. There is no risk of mixing them up at all.

On i386, all symbols (except for microsoft mangled and certain other calling conventions) start with an extra underscore, so itanium mangled names start with __Z. This is currently handled by always manually stripping one underscore on i386 before calling the demangler, but could be skipped as well if we use a more tolerant demangler. It could also be kept to avoid the risk of demangling a symbol like Znwy that originally didn't start with an underscore.

I did not expect the solution to end up with an extra parameter StrictPrefix. The additional complexity was not what I intended. If mingw has to live with both mangling schemes, I want to first check if the demangling code will be used in more than one places. If yes, I am not against deleting StrictPrefix. The overhead to demangle __Z, ___Z or ___Z prefixed names for ELF should be small.

It's not at all about the two different mangling schemes.

It's only about whether we artifically should make the general itanium demangler routine more strict than it is right now, or accept that there's a small risk of demangling something that isn't supposed to, but this is already a risk that all existing callers of the general llvm demangle library are ok with.

First, I'd prefer a solution that does not need to annotate call sites like: demangle(demangleInput, /*strictPrefix=*/true). This is prerequisite.

Next, if there is some way to not demangle __Z, ___Z or ___Z prefixed names for ELF, that will be great.. If mingw or apple may need more underscores, a new function will look good to me. That will document their extensions to the Itanium mangling scheme. However, if doing this would increase code complexity significantly, I'm fine with using a unified interface.

[mstorsjo]

In D67301#1681958, @MaskRay wrote:

If a call site of llvm::demangle deals either exclusively Itanium mangled names, or exclusively MSVC-style mangled names. I don't see why we must have a single entry point (llvm::demangle) for demangling. Two entry points (for Itanium and MSVC-style) may be better. It avoids the problem that some platforms are unnecessarily affected by special rules from some particular platforms.

No, there's one single call site in the COFF linker, which right now does this:

demangleMSVC()
if (failedToDemangle && mingw)
    demangleItanium()

As the itanium and MSVC mangling schemes are completely orthogonal, this is just pointless, as the unified demangle function already can distinguish between the two just fine. This is what spurred this patch (requested by @rnk) to begin with.

The single entry point, llvm::demangle, which handles both MSVC and itanium, already exists, doing exactly this. It just happens to be more lax when it comes to itanium mangling.

First, I'd prefer a solution that does not need to annotate call sites like: demangle(demangleInput, /*strictPrefix=*/true). This is prerequisite.

So is the issue that the extra parameter is very verbose? Would llvm::demangleStrict(demangleInput) be better?

Next, if there is some way to not demangle __Z, ___Z or ___Z prefixed names for ELF, that will be great.. If mingw or apple may need more underscores, a new function will look good to me. That will document their extensions to the Itanium mangling scheme. However, if doing this would increase code complexity significantly, I'm fine with using a unified interface.

The point of the patchset is to remove redundant boilerplate code in lld, when there's a general unified function in the llvm demangle library already which does this. There's no point in a new function for mingw/apple that would support more underscores, as the existing llvm::demangle function does it just fine. If you want the ELF linker to be very strict about demangling, we could add a llvm::demangleStrict that the ELF linker could use, if that's any better?

Or just keep a small wrapper in lld, like this:

std::string demangleItanium(std::string input) {
  if (!input.startswith("_Z"))
    return input;
  return llvm::demangle(input);
}

[mstorsjo]

As it seems to be hard to agree on what should be done and how, I'm trying to split this up into separate smaller bits, which hopefully should get this patch moving forward easier.

[rnk]

In D67301#1681906, @MaskRay wrote:

Is there a scenario where both Itanium and Microsoft mangling schemes should be tried? (mingw?)

Well, I was pushing for exactly the opposite. The schemes are easily distinguished: leading ? or leading _+Z. It's easy to imagine a user using LLD to link together mingw (or even just @compnerd's x86_64-windows-itanium objects) and MSVC COFF files into the same program as long as they only talk to each other through plain C symbols. If we just handle everything all at once, there's less likelihood that down the line someone will file a bug asking us to add the other scheme along some strange codepath.

Anyway, this is my viewpoint, but I'm not writing the code, so @mstorsjo, please do not feel obligated to push this any further. :)

[mstorsjo]

@rnk - Does the smaller scope of this patch make sense to you? It retains the point of unifying all the different manglings for the COFF linker behind the single unified interface, but without touching the rest of LLD at the same time.

[mstorsjo]

Ping @rnk

[rnk]

OK, so this is NFC for ELF, but has the relaxed __Z handling for COFF. lgtm

Sorry for the goose chase. :)

[mstorsjo]

In D67301#1684515, @rnk wrote:

OK, so this is NFC for ELF, but has the relaxed __Z handling for COFF. lgtm

Yup, it uses the relaxed _Z handling which can match __Z as well (which should be not too plausible, and that's reserved identifiers in C). But on i386, I manually still strip out the leading underscore, if present, so a C level identifier which just starts with capital Z, which as an cdecl symbol on i386 ends up as _Z..., won't match. (This is a slightly more plausible scenario in my opinion.)

This extra handling just uses two pretty harmless lines of code, which I don't even touch in this patch, if (config->machine == I386) demangleInput.consume_front("_");. They could be dropped, making the demangling even more lax, but I don't see much harm in keeping them.

I'll push this (plus the two other smaller ELF related cleanups that were ok'd) tomorrow then.

lld/COFF/CMakeLists.txt

add_lld_library(lldCOFF
 
   LINK_COMPONENTS
   ${LLVM_TARGETS_TO_BUILD}
   BinaryFormat
   Core
   DebugInfoCodeView
   DebugInfoMSF
   DebugInfoPDB
+  Demangle
   LibDriver
   LTO
   MC
   Object
   Option
   Support
   Symbolize
   WindowsManifest

lld/COFF/Symbols.cpp

 //===- Symbols.cpp --------------------------------------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #include "Symbols.h"
 #include "InputFiles.h"
 #include "lld/Common/ErrorHandler.h"
 #include "lld/Common/Memory.h"
 #include "lld/Common/Strings.h"
 #include "llvm/ADT/STLExtras.h"
+#include "llvm/Demangle/Demangle.h"
 #include "llvm/Support/Debug.h"
 #include "llvm/Support/raw_ostream.h"
 
 using namespace llvm;
 using namespace llvm::object;
 
 using namespace lld::coff;
 
 namespace lld {
 
 static_assert(sizeof(SymbolUnion) <= 48,
               "symbols should be optimized for memory usage");
 
 // Returns a symbol name for an error message.
-static std::string demangle(StringRef symName) {
+static std::string maybeDemangleSymbol(StringRef symName) {
   if (config->demangle) {
-    if (Optional<std::string> s = demangleMSVC(symName))
-      return *s;
-    if (config->mingw) {
-      StringRef demangleInput = symName;
-      std::string prefix;
-      if (demangleInput.consume_front("__imp_"))
-        prefix = "__declspec(dllimport) ";
-      if (config->machine == I386)
-        demangleInput.consume_front("_");
-      if (Optional<std::string> s = demangleItanium(demangleInput))
-        return prefix + *s;
-    }
+    StringRef demangleInput = symName;
+    std::string demangled = demangle(demangleInput);
+    if (demangled != demangleInput)
+      return prefix + demangled;
   }
   return symName;
 }
-std::string toString(coff::Symbol &b) { return demangle(b.getName()); }
+std::string toString(coff::Symbol &b) {
+  return maybeDemangleSymbol(b.getName());
+}
 std::string toCOFFString(const Archive::Symbol &b) {
-  return demangle(b.getName());
+  return maybeDemangleSymbol(b.getName());
 }
 
 namespace coff {
 
 StringRef Symbol::getName() {
   // COFF symbol names are read lazily for a performance reason.
   // Non-external symbol names are never used by the linker except for logging
   // or debugging. Their internal references are resolved not by name but by

lld/Common/Strings.cpp

Optional<std::string> lld::demangleItanium(StringRef name) {
   char *buf = itaniumDemangle(name.str().c_str(), nullptr, nullptr, nullptr);
   if (!buf)
     return None;
   std::string s(buf);
   free(buf);
   return s;
 }
 
-Optional<std::string> lld::demangleMSVC(StringRef name) {
-  std::string prefix;
-  if (name.consume_front("__imp_"))
-    prefix = "__declspec(dllimport) ";
-
-  // Demangle only C++ names.
-  if (!name.startswith("?"))
-    return None;
-
-  char *buf = microsoftDemangle(name.str().c_str(), nullptr, nullptr, nullptr);
-  if (!buf)
-    return None;
-  std::string s(buf);
-  free(buf);
-  return prefix + s;
-}
-
 StringMatcher::StringMatcher(ArrayRef<StringRef> pat) {
   for (StringRef s : pat) {
     Expected<GlobPattern> pat = GlobPattern::create(s);
     if (!pat)
       error(toString(pat.takeError()));
     else
       patterns.push_back(*pat);
   }

lld/include/lld/Common/Strings.h

 #include "llvm/Support/GlobPattern.h"
 #include <string>
 #include <vector>
 
 namespace lld {
 // Returns a demangled C++ symbol name. If Name is not a mangled
 // name, it returns Optional::None.
 llvm::Optional<std::string> demangleItanium(llvm::StringRef name);
-llvm::Optional<std::string> demangleMSVC(llvm::StringRef s);
 
 std::vector<uint8_t> parseHex(llvm::StringRef s);
 bool isValidCIdentifier(llvm::StringRef s);
 
 // Write the contents of the a buffer to a file
 void saveBuffer(llvm::StringRef buffer, const llvm::Twine &path);
 
 // This class represents multiple glob patterns.

lld/test/COFF/undefined-symbol-itanium-i386.s

 # REQUIRES: x86
 # RUN: llvm-mc -triple=i386-windows-gnu -filetype=obj -o %t.o %s
 # RUN: not lld-link /lldmingw /out:%t.exe %t.o 2>&1 | FileCheck %s
 # RUN: not lld-link /lldmingw /out:%t.exe /demangle %t.o 2>&1 | FileCheck %s
 # RUN: not lld-link /lldmingw /out:%t.exe /demangle:no %t.o 2>&1 | FileCheck --check-prefix=NODEMANGLE %s
 
 # NODEMANGLE: error: undefined symbol: __Z3fooi
 # NODEMANGLE: error: undefined symbol: __Z3barPKc
 # NODEMANGLE: error: undefined symbol: __imp___Z3bazv
+# NODEMANGLE: error: undefined symbol: _Z3fooi
 
 # CHECK: error: undefined symbol: foo(int)
 # CHECK-NEXT: >>> referenced by {{.*}}.o:(_main)
 # CHECK-NEXT: >>> referenced by {{.*}}.o:(_main)
 # CHECK-EMPTY:
 # CHECK-NEXT: error: undefined symbol: bar(char const*)
 # CHECK-NEXT: >>> referenced by {{.*}}.o:(_main)
 # CHECK-NEXT: >>> referenced by {{.*}}.o:(_f1)
 # CHECK-EMPTY:
 # CHECK-NEXT: error: undefined symbol: __declspec(dllimport) baz()
 # CHECK-NEXT: >>> referenced by {{.*}}.o:(_f2)
+# CHECK-EMPTY:
+# CHECK-NEXT: error: undefined symbol: _Z3fooi
+# CHECK-NEXT: >>> referenced by {{.*}}.o:(_f2)
 
         .section        .text,"xr",one_only,_main
 .globl _main
 _main:
   call  __Z3fooi
   call  __Z3fooi
   call  __Z3barPKc
 
 _f1:
   call  __Z3barPKc
 .Lfunc_end1:
 
         .section        .text,"xr",one_only,_f2
 .globl _f2
 _f2:
   call  *__imp___Z3bazv
+  call  _Z3fooi

lld/test/COFF/undefined-symbol.s

 # REQUIRES: x86
 # RUN: llvm-mc -triple=x86_64-windows-msvc -filetype=obj -o %t.obj %s
 # RUN: not lld-link /out:%t.exe %t.obj 2>&1 | FileCheck %s
 # RUN: not lld-link /out:%t.exe /demangle %t.obj 2>&1 | FileCheck %s
 # RUN: not lld-link /out:%t.exe /demangle:no %t.obj 2>&1 | FileCheck --check-prefix=NODEMANGLE %s
 
 # NODEMANGLE: error: undefined symbol: ?foo@@YAHXZ
 # NODEMANGLE: error: undefined symbol: ?bar@@YAHXZ
 # NODEMANGLE: error: undefined symbol: __imp_?baz@@YAHXZ
+# NODEMANGLE: error: undefined symbol: __imp_undecorated
 
 # CHECK: error: undefined symbol: int __cdecl foo(void)
 # CHECK-NEXT: >>> referenced by {{.*}}.obj:(main)
 # CHECK-NEXT: >>> referenced by {{.*}}.obj:(main)
 # CHECK-EMPTY:
 # CHECK-NEXT: error: undefined symbol: int __cdecl bar(void)
 # CHECK-NEXT: >>> referenced by {{.*}}.obj:(main)
 # CHECK-NEXT: >>> referenced by {{.*}}.obj:(f1)
 # CHECK-EMPTY:
 # CHECK-NEXT: error: undefined symbol: __declspec(dllimport) int __cdecl baz(void)
 # CHECK-NEXT: >>> referenced by {{.*}}.obj:(f2)
+# CHECK-EMPTY:
+# CHECK-NEXT: error: undefined symbol: __imp_undecorated
+# CHECK-NEXT: >>> referenced by {{.*}}.obj:(f2)
 
         .section        .text,"xr",one_only,main
 .globl main
 main:
   call  "?foo@@YAHXZ"
   call  "?foo@@YAHXZ"
   call  "?bar@@YAHXZ"
 
 f1:
   call  "?bar@@YAHXZ"
 .Lfunc_end1:
 
         .section        .text,"xr",one_only,f2
 .globl f2
 f2:
   callq  *"__imp_?baz@@YAHXZ"(%rip)
+  callq *__imp_undecorated(%rip)