[PATCH] [mc-coff] Forward Linker Option flags into the .drectve section

[Robinson, Paul]

From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
bounces at cs.uiuc.edu] On Behalf Of Reid Kleckner
> On Fri, Apr 26, 2013 at 12:04 PM,  <Dario_Domizioli at sn.scee.net> wrote:
> > Hi Reid.
> >
> > It seems to me that this patch, combined with your clang one, assumes
> a
> > Windows linker.
> > (sorry I'm replying to this patch and then referencing the previous
> one,
> > but I can't reply to both email threads at the same time)
> 
> Nothing about this LLVM patch necessarily assumes a windows linker.
> This patch implements the obvious semantics of the "Linker Options"
> metadata as I understand them for COFF.  Maybe Daniel can say more
> about how he envisioned this working in the context of different
> linkers with different flags.
> 
> > Your approach is to store the full "/DEPLIBS:<libname>" string
> directly in
> > the llvm metadata, and I see the string is created in the
> > Sema::ActOnPragmaMSComment function which is target-independent;
> however,
> > that string only makes sense to the Windows linker, I think.
> > It is conceivable that people will want to extend support for "#pragma
> > comment lib" for other targets (for example ELF) and other linkers; in
> > fact that is also a feature request from our customers. Since the
> pragma
> > is a frontend feature, it is exposed to all users and it could be
> useful
> > to people in general.
> 
> Yeah, doing that lowering in Sema seems wrong.
> 
> After thinking about the clang side of this patch, I think it would be
> better to hook up a PPCallbacks implementation to CodeGenModule.
> There wasn't any prior art for this, so I tried to plough ahead with
> wiring it through Sema.

Our initial cut did the same, was easier to hook up through Sema.

> Do you and your customers want to support the spelling "#pragma
> comment(lib)" for auto-linking, or just something else like it?  IMO
> the name of this pragma is terrible and we shouldn't be increasing
> support for it unless there's a compatibility argument for a large
> body of existing code.  On Windows, there are various headers that
> automatically link the corresponding .lib already, so we want it
> there.
>
> I was working under the assumption that this pragma would only be used
> for COFF and that the linker would understand /defaultlib, since
> presumably it already has to understand /export to implement
> __declspec(dllexport).

We were asked for Windows source compatibility with our ELF target.
We don't use /export for __declspec(dllexport).
--paulr

> 
> > In fact, the discussion of Daniel's RFC at some point mentions either
> > implementing a neutral representation in the metadata (such as a
> "named
> > libraries" flag in addition to the "linker options" one) or having a
> > target-specific hook to set the linker options accordingly. Daniel
> votes
> > for the target-specific hook.
> > See http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-
> January/058246.html
> 
> Sure, I could push that into a target hook.