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

[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.

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).

> 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.