<div>I think that I've probably declared my option inappropriately. It was:<br></div><div><br></div><div>// Options.td</div><div><span class="s1">def fmyopt_EQ : Joined<["-"], "fmyopt=">, Group<f_clang>, Flags<[CC1Option]>,</span><br></div><p class="p1"><span class="s1"><span class="Apple-converted-space"> </span>HelpText<"...">;</span><br></p><div>I think that the choice of whether or not to propagate it to the linker comes from here:<br></div><div><br></div><p class="p1"><span class="s1">static</span><span class="s2"> </span><span class="s1">bool</span><span class="s2"> </span><span class="s3">forwardToGCC</span><span class="s2">(</span><span class="s1">const</span><span class="s2"> Option &O) {</span><br></p><p class="p2"><span class="s4"><span class="Apple-converted-space"> </span></span><span class="s2">// Don't forward inputs from the original command line.<span class="Apple-converted-space"> </span>They are added from</span><br></p><p class="p2"><span class="s4"><span class="Apple-converted-space"> </span></span><span class="s2">// InputInfoList.</span><br></p><p class="p1"><span class="s2"><span class="Apple-converted-space"> </span></span><span class="s5">return</span><span class="s2"> O.</span><span class="s3">getKind</span><span class="s2">() != Option::InputClass &&</span><br></p><p class="p1"><span class="s2"><span class="Apple-converted-space"> </span>!O.</span><span class="s3">hasFlag</span><span class="s2">(options::DriverOption) && !O.</span><span class="s3">hasFlag</span><span class="s2">(options::LinkerInput);</span><br></p><p class="p1"><span class="s2">}</span><br></p><div><br></div><div><span class="s2">i.e. the LinkerInput flag. Perhaps this is implied by CC1Option in my Options.td line?</span><br></div><div><br></div><div><span class="s2">I tried changing to</span><br></div><div><br></div><div><span class="s1">def fmyopt_EQ : Joined<["-"], "fmyopt=">, Group<f_clang>, Flags<[DriverOption]>,</span><br></div><p class="p1"><span class="s1"><span class="Apple-converted-space"> </span>HelpText<"...">;</span><br></p><div>but now my option is no longer recognized in the compilation phase.</div><div><br></div><div>Hmm, wondering if I should have put this in CC1Options.td instead, which I just spotted?</div><div><br></div><div class="protonmail_signature_block "><div class="protonmail_signature_block-user "><div>--<br></div><div>Peeter<br></div></div><div class="protonmail_signature_block-proton protonmail_signature_block-empty"><br></div></div><div><br></div><blockquote class="protonmail_quote" type="cite"><div>-------- Original Message --------<br></div><div>Subject: RE: [cfe-dev] how to avoid passing new clang front end option to the linker?<br></div><div>Local Time: March 15, 2017 2:25 PM<br></div><div>UTC Time: March 15, 2017 6:25 PM<br></div><div>From: paul.robinson@sony.com<br></div><div>To: Peeter Joot <peeterjoot@protonmail.com><br></div><div>cfe-dev@lists.llvm.org <cfe-dev@lists.llvm.org><br></div><div><br></div><div> <br></div><div class="WordSection1"><p class="MsoNormal"><span style="color:rgb(31, 73, 125)" class="colour"><span style="font-family:Calibri, sans-serif" class="font"><span style="font-size:11pt" class="size">The linker command line would be constructed in the driver (clang/lib/Driver/…) and exactly where the code is depends on your triple. You could grep for 'Linker::ConstructJob'
and see what looks most likely, or try stepping through the driver in a debugger to see which one is invoked. I am a little surprised that arbitrary –f options would be passed through in the link phase.</span></span></span><br></p><p class="MsoNormal"><a name="_MailEndCompose"><span style="color:rgb(31, 73, 125)" class="colour"><span style="font-family:Calibri, sans-serif" class="font"><span style="font-size:11pt" class="size">HTH,</span></span></span></a><br></p><p class="MsoNormal"><span style="color:rgb(31, 73, 125)" class="colour"><span style="font-family:Calibri, sans-serif" class="font"><span style="font-size:11pt" class="size">--paulr</span></span></span><br></p><p class="MsoNormal"><span style="color:rgb(31, 73, 125)" class="colour"><span style="font-family:Calibri, sans-serif" class="font"><span style="font-size:11pt" class="size"> </span></span></span><br></p><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-family:Tahoma, sans-serif" class="font"><span style="font-size:10pt" class="size">From:</span></span></b><span style="font-family:Tahoma, sans-serif" class="font"><span style="font-size:10pt" class="size"> cfe-dev [mailto:cfe-dev-bounces@lists.llvm.org] <b>On Behalf Of </b>Peeter Joot via cfe-dev<br> <b>Sent:</b> Wednesday, March 15, 2017 8:10 AM<br> <b>To:</b> cfe-dev@lists.llvm.org<br> <b>Subject:</b> [cfe-dev] how to avoid passing new clang front end option to the linker?</span></span></p></div></div><p class="MsoNormal"> <br></p><div><p class="MsoNormal">I'm attempting to implement a new clang front end option for my project (<span class="s1">-fmyopt=blah)</span>, and have made the changes required that I can access and act on it in my Target class when compiling. When linking, it causes
a bit of trouble, as clang passes it on to gcc in the link phase:<br></p></div><p class="p1"><span class="apple-converted-space"> </span><span class="s1">"/usr/lib64/ccache/gcc" -g -D QSIZE -fpic -MD -fmyopt=blah -v -m64 -o tryit /run/user/1002/tryit-46641b.o</span><br></p><p class="p1">which gcc objects to. <br></p><div><p class="MsoNormal"> <br></p></div><div><p class="MsoNormal">What part of the code is the link command line constructed in, and what is the mechanism used to select which options get passed to other stages (or an example of that)?<br></p></div><div><p class="MsoNormal"> <br></p></div><div><div><div><p class="MsoNormal">--<br></p></div><div><p class="MsoNormal">Peeter<br></p></div></div><div><p class="MsoNormal"> <br></p></div></div><div><p class="MsoNormal"> <br></p></div></div></div></blockquote><div><br></div>