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

Peter Collingbourne peter at pcc.me.uk
Mon Jun 29 15:56:34 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
----------------
ygao wrote:
> 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.
Okay, I'll send out a separate change to clean up those interfaces.

================
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();
       }
----------------
ygao wrote:
> 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.
Yes, as I mentioned in my first message `lib` pragmas are quoted by the front end. Sorry if that wasn't clear.

http://reviews.llvm.org/D10548

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






More information about the llvm-commits mailing list