[PATCH] Teach LTOModule to emit linker flags for dllexported symbols, plus interface cleanup.

Yunzhong Gao Yunzhong_Gao at playstation.sony.com
Mon Jun 29 15:51:12 PDT 2015


================
Comment at: include/llvm-c/lto.h:286
@@ -285,1 +285,3 @@
+ * Deprecated. Now returns an empty list.
+ *
  * \since LTO_API_VERSION=8
----------------
pcc wrote:
> ygao wrote:
> > I'm wondering whether it might be better to remove these two functions instead of changing their behaviors silently.
> Works for me. I think your linker is the only one that depends on this interface, so if it wouldn't cause you too much pain I'd rather just do that.
I think I'd prefer to remove these two functions if no other client would be affected. Probably will have to bump up LTO_API_VERSION.
And with your change, lto_module_get_num_linkeropt() will always return 1, and therefore is not too useful either.

================
Comment at: lib/LTO/LTOModule.cpp:655
@@ -651,13 +654,3 @@
         MDString *MDOption = cast<MDString>(MDOptions->getOperand(ii));
-        // FIXME: Make StringSet::insert match Self-Associative Container
-        // requirements, returning <iter,bool> rather than bool, and use that
-        // here.
-        StringRef Op =
-            _linkeropt_strings.insert(MDOption->getString()).first->first();
-        StringRef DepLibName =
-            _target->getObjFileLowering()->getDepLibFromLinkerOpt(Op);
-        if (!DepLibName.empty())
-          _deplibs.push_back(DepLibName.data());
-        else if (!Op.empty())
-          _linkeropts.push_back(Op.data());
+        OS << " " << MDOption->getString();
       }
----------------
pcc wrote:
> ygao wrote:
> > Is it safe to concatenate all the linker options into one? What if the #pragma comment(lib, ...) or #pragma comment(linker, ...) string also contains space characters?
> In a regular object file, the contents of `linker` pragmas are concatenated with space characters between them before being emitted in the `.directve` section; i.e. the compiler does not quote the individual string literals that appear in the pragmas, they just appear as a bag of bytes in the section. `lib` pragmas are quoted early on if needed but go through the same mechanism as `linker` (see e.g. `qualifyWindowsLibrary` in clang).  This means that there is no difference at the object file level between
> 
>   #pragma comment(linker, "/defaultlib:foo /defaultlib:bar")
> 
> and
> 
>   #pragma comment(linker, "/defaultlib:foo")
>   #pragma comment(linker, "/defaultlib:bar")
> 
> This is reflected in the LTO APIs.
I was thinking of use cases like:
```
#pragma comment(lib, "spaced library");
#pragma comment(lib, "strange names /include:slashes");
```
It may have already been handled by the front end. Not sure.

http://reviews.llvm.org/D10548

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list