[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