This is an archive of the discontinued LLVM Phabricator instance.

Add a utility function to add target information to a command line
ClosedPublic

Authored by zarko on Sep 30 2015, 4:48 PM.

Details

Summary

This diff adds addTargetAndModeForProgramName, a utility function that will add appropriate -target foo and --driver-mode=g++ tokens to a command line for driver invocations of the form a/b/foo-g++. It is intended to support tooling: for example, should a compilation database record some invocation of foo-g++ without these implicit flags, a Clang tool may use this function to add them back.

Note that a compilation database won't necessarily store these invocations without their corresponding implicit flags. Some may use addTargetAndModeForProgramName when the database is first written out so that later readers don't need to repeat the operation.

Diff Detail

Event Timeline

zarko updated this revision to Diff 36163.Sep 30 2015, 4:48 PM
zarko retitled this revision from to Add a utility function to add target information to a command line.
zarko updated this object.
zarko added reviewers: rnk, echristo, klimek.
zarko added a subscriber: cfe-commits.
echristo edited edge metadata.Sep 30 2015, 7:31 PM
echristo added a subscriber: echristo.

This seems a little odd, could you explain in a bit more detail? Me not
understanding I imagine. :)

-eric

klimek accepted this revision.Oct 1 2015, 12:51 AM
klimek edited edge metadata.

LG

include/clang/Tooling/Tooling.h
437

Add that for tools, CommandLine[0] will need to be a tool path relatively to which the builtin headers can be found.

This revision is now accepted and ready to land.Oct 1 2015, 12:51 AM

This seems a little odd, could you explain in a bit more detail? Me not
understanding I imagine. :)

Seems to be explained well in the comments?
If the compilation database contains:
i686-linux-android-g++ <flags> <file>
Then <file> might only be correctly parseable with the target implied; usually the driver figures that out from argv[0], but for tools, argv[0] is the tool name.

BTW as Manuel is happy it's fine with me. Still curious though.

zarko updated this revision to Diff 36266.Oct 1 2015, 9:57 AM
zarko edited edge metadata.

Address comment comments.

zarko marked an inline comment as done.Oct 1 2015, 10:08 AM

Thanks; would someone with commit access land this?

echristo: for a more concrete example, imagine a source code indexer that collects up dependencies. This is a Clang tool that gets called by the build system for each translation unit and is provided with the path to the compiler it would use to build it along with the arguments to that compiler. The indexer is unlikely to be on the same path as the compiler, but the indexer's path needs to be preserved because of the way Clang tools search for resources.

The only important part of the path to the compiler is the compiler's name, because sometimes the name contains information about the target or driver mode that affects how the indexer should interpret the translation unit. This function applies the logic that Clang's driver uses to deduce that information; it then adds arguments that cause the tooling infrastructure to correctly interpret the code.

klimek added a comment.Oct 5 2015, 2:38 AM

Did you test this with cmake? I get undef reference functions when linking ToolingTest...

zarko updated this revision to Diff 36529.Oct 5 2015, 10:55 AM

Copy a dependency from a test Makefile to its CMakeLists.

zarko added a comment.Oct 5 2015, 10:55 AM

I'd tested with the Makefile; it looks like CMakeLists for the unit tests isn't linking ${LLVM_TARGETS_TO_BUILD}. I've updated the diff.

klimek closed this revision.Oct 6 2015, 3:47 AM

Submitted as r249391.