[cfe-dev] how to avoid passing new clang front end option to the linker?

[Mehdi Amini via cfe-dev]

> On Mar 15, 2017, at 12:11 PM, Peeter Joot via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> I think that I've probably declared my option inappropriately.  It was:
> 
> // Options.td
> def fmyopt_EQ : Joined<["-"], "fmyopt=">, Group<f_clang>, Flags<[CC1Option]>,
>   HelpText<"...">;
> 
> I think that the choice of whether or not to propagate it to the linker comes from here:
> 
> static bool forwardToGCC(const Option &O) {
> 
>   // Don't forward inputs from the original command line.  They are added from
> 
>   // InputInfoList.
> 
>   return O.getKind() != Option::InputClass &&
> 
>          !O.hasFlag(options::DriverOption) && !O.hasFlag(options::LinkerInput);
> 
> }
> 
> 
> i.e. the LinkerInput flag.  Perhaps this is implied by CC1Option in my Options.td line?


I’m not sure, there is a ! in front the the LinkerInput test, so it’ll return true if it is *not* a LinkerInput.


> I tried changing to
> 
> def fmyopt_EQ : Joined<["-"], "fmyopt=">, Group<f_clang>, Flags<[DriverOption]>,
>   HelpText<"...”>;
> 

Maybe:

> def fmyopt_EQ : Joined<["-"], "fmyopt=">, Group<f_clang>, Flags<[DriverOption, CC1Option]>,

?

— 
Mehdi



> but now my option is no longer recognized in the compilation phase.
> 
> Hmm, wondering if I should have put this in CC1Options.td instead, which I just spotted?
> 
> --
> Peeter
> 
> 
>> -------- Original Message --------
>> Subject: RE: [cfe-dev] how to avoid passing new clang front end option to the	linker?
>> Local Time: March 15, 2017 2:25 PM
>> UTC Time: March 15, 2017 6:25 PM
>> From: paul.robinson at sony.com
>> To: Peeter Joot <peeterjoot at protonmail.com>
>> cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>
>> 
>> 
>> 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.
>> 
>> HTH, <>
>> --paulr
>> 
>>  
>> 
>> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Peeter Joot via cfe-dev
>> Sent: Wednesday, March 15, 2017 8:10 AM
>> To: cfe-dev at lists.llvm.org
>> Subject: [cfe-dev] how to avoid passing new clang front end option to the linker?
>> 
>>  
>> 
>> I'm attempting to implement a new clang front end option for my project (-fmyopt=blah), 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:
>> 
>>  "/usr/lib64/ccache/gcc" -g -D QSIZE -fpic -MD -fmyopt=blah -v -m64 -o tryit /run/user/1002/tryit-46641b.o
>> 
>> which gcc objects to.  
>> 
>>  
>> 
>> 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)?
>> 
>>  
>> 
>> --
>> 
>> Peeter
>> 
>>  
>> 
>>  
>> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170315/9cde3c2d/attachment.html>