how to avoid passing new clang front end option to the linker?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

how to avoid passing new clang front end option to the linker?

Sumner, Brian via cfe-dev
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: how to avoid passing new clang front end option to the linker?

Sumner, Brian via cfe-dev

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:[hidden email]] On Behalf Of Peeter Joot via cfe-dev
Sent: Wednesday, March 15, 2017 8:10 AM
To: [hidden email]
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: how to avoid passing new clang front end option to the linker?

Sumner, Brian via cfe-dev
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 tried changing to

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

  HelpText<"...">;

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
To: Peeter Joot <[hidden email]>


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:[hidden email]] On Behalf Of Peeter Joot via cfe-dev
Sent: Wednesday, March 15, 2017 8:10 AM
To: [hidden email]
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: how to avoid passing new clang front end option to the linker?

Sumner, Brian via cfe-dev

On Mar 15, 2017, at 12:11 PM, Peeter Joot via cfe-dev <[hidden email]> 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
To: Peeter Joot <[hidden email]>


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 [[hidden email]] On Behalf Of Peeter Joot via cfe-dev
Sent: Wednesday, March 15, 2017 8:10 AM
To: [hidden email]
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: how to avoid passing new clang front end option to the linker?

Sumner, Brian via cfe-dev

The debugger shows that this forwardToGcc path does get hit.  Setting a breakpoint just before it, I find my option:

6681    for (const auto &A : Args) {

6682      if (A->getOption().matches(options::OPT_fmyopt_EQ)) { 

6683         printf("here\n");

6684      }

6685      if (forwardToGCC(A->getOption())) {



$3 = {

  Opt = {

    Info = 0x7ffff43f00d0 <InfoTable+28336>,

    Owner = 0x45c170

  },

  BaseArg = 0x0,

  Spelling = {

    static npos = 18446744073709551615,

    Data = 0x7fffffffdd1e "-fmyopt=extended", 

    Length = 10

  },

  ...

}


then in the forward code:

/home/pjoot/llvm.pragmas/tools/clang/lib/Driver/Tools.cpp:295

295      auto pk = O.getKind() != Option::InputClass ;

296      auto pd = O.hasFlag(options::DriverOption) ;

297      auto pl = O.hasFlag(options::LinkerInput);

298      return pk && !pd && !pl;

$4 = true

$5 = false

$6 = false

DriverOption and LinkerInput are both false so the result is true:

$7 = true

I then see my flag get inserted into the CmdArgs for the gcc command line (although I can't confirm easily in the debugger, since the SmallString class is garbage to gdb).

Perhaps I should be setting DriverOption in Options.td along with CC1Option?

--
Peeter


-------- Original Message --------
Subject: Re: [cfe-dev] how to avoid passing new clang front end option to the linker?
Local Time: March 15, 2017 7:19 PM
UTC Time: March 15, 2017 11:19 PM
To: Peeter Joot <[hidden email]>


On Mar 15, 2017, at 12:11 PM, Peeter Joot via cfe-dev <[hidden email]> 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
To: Peeter Joot <[hidden email]>


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 [[hidden email]] On Behalf Of Peeter Joot via cfe-dev
Sent: Wednesday, March 15, 2017 8:10 AM
To: [hidden email]
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
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: how to avoid passing new clang front end option to the linker?

Sumner, Brian via cfe-dev

That's very odd, because other options that are defined in similar ways (e.g. –fparse-all-comments) do not get forwarded to the linker.  Comparing how your option behaves relative to other similar options might help diagnose the problem.

--paulr

 

From: Peeter Joot [mailto:[hidden email]]
Sent: Thursday, March 16, 2017 5:04 AM
To: Mehdi Amini
Cc: Robinson, Paul; [hidden email]
Subject: Re: [cfe-dev] how to avoid passing new clang front end option to the linker?

 

The debugger shows that this forwardToGcc path does get hit.  Setting a breakpoint just before it, I find my option:

6681    for (const auto &A : Args) {

6682      if (A->getOption().matches(options::OPT_fmyopt_EQ)) { 

6683         printf("here\n");

6684      }

6685      if (forwardToGCC(A->getOption())) {

 

 

$3 = {

  Opt = {

    Info = 0x7ffff43f00d0 <InfoTable+28336>,

    Owner = 0x45c170

  },

  BaseArg = 0x0,

  Spelling = {

    static npos = 18446744073709551615,

    Data = 0x7fffffffdd1e "-fmyopt=extended", 

    Length = 10

  },

  ...

}

 

then in the forward code:

 

/home/pjoot/llvm.pragmas/tools/clang/lib/Driver/Tools.cpp:295

295      auto pk = O.getKind() != Option::InputClass ;

296      auto pd = O.hasFlag(options::DriverOption) ;

297      auto pl = O.hasFlag(options::LinkerInput);

298      return pk && !pd && !pl;

$4 = true

$5 = false

$6 = false

DriverOption and LinkerInput are both false so the result is true:

$7 = true

I then see my flag get inserted into the CmdArgs for the gcc command line (although I can't confirm easily in the debugger, since the SmallString class is garbage to gdb).

 

Perhaps I should be setting DriverOption in Options.td along with CC1Option?

 

--

Peeter

 

 

-------- Original Message --------

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

Local Time: March 15, 2017 7:19 PM

UTC Time: March 15, 2017 11:19 PM

To: Peeter Joot <[hidden email]>

 

 

On Mar 15, 2017, at 12:11 PM, Peeter Joot via cfe-dev <[hidden email]> 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

To: Peeter Joot <[hidden email]>

 

 

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 [[hidden email]] On Behalf Of Peeter Joot via cfe-dev
Sent: Wednesday, March 15, 2017 8:10 AM
To: [hidden email]
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 mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...