aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/cpp/CppLinkActionBuilder.java
Commit message (Collapse)AuthorAge
* Extract logic for dealing with CROSSTOOL values and build variables into ↵Gravatar rosica2018-05-14
| | | | | | | separate class RELNOTES: None. PiperOrigin-RevId: 196517537
* Remove cppConfiguration from LinkBuildVariablesGravatar hlopko2018-05-08
| | | | | | | | | This is to simplify the API that will eventually be exposed to Skylark. Working towards #4571. RELNOTES: None. PiperOrigin-RevId: 195785588
* Rename LinkStaticness to LinkingMode and unify with the other LinkingMode.Gravatar hlopko2018-05-07
| | | | | RELNOTES: None. PiperOrigin-RevId: 195777400
* Rename Staticness to LinkerOrArchiver.Gravatar hlopko2018-05-07
| | | | | | | | | Staticness is confusing, I always have to investigate which is Staticness and which is LinkStaticness, and even in isolation staticness is not a great name. I believe LinkerOrArchiver is a better name :) RELNOTES: None. PiperOrigin-RevId: 195674810
* Consolidating start/end lib archive expansion Take 3Gravatar Googler2018-05-03
| | | | | | | | Different places in the link logic were in charge of expanding start/end lib archives, causing discrepancies. This CL gets rid of the special iteration in Link.java and makes LibrariesToLinkCollecter solely responsible for mapping static libraries to their object files on the link command l... RELNOTES: Fixing start/end lib expansion for linking. There were many cases where archive files were still being used with toolchains that support start/end lib. This change consolidates the places that make that decision so they can be more consistent. PiperOrigin-RevId: 195258075
* Thread legacy compile flags through CcToolchainProvider for compile build ↵Gravatar hlopko2018-05-03
| | | | | | | | | | variables This cl shuffles code around so that compile build variables don't require rule context and CppConfiguration. RELNOTES: None. PiperOrigin-RevId: 195249548
* Do not add flags from linking_mode_flags section when the toolchain definesGravatar hlopko2018-05-02
| | | | | | | | | | | | | | | | | | | corresponding features. Therefore when both linking_mode_flags { mode: DYNAMIC } and feature { name: "dynamic_linking_mode" } are provided, bazel will only take flags from the feature. The same applies to mode: STATIC and static_linkin_mode feature respectively. mode: MOSTLY_STATIC_LIBRARIES is covered under dynamic_linking_mode for action "c++-link-dynamic-library". mode: FULLY_STATIC is handled separately. This is needed to provide a way of incremental migration towards legacy-flags-free crosstool. This is encore of https://github.com/bazelbuild/bazel/commit/fd9a0958a989cac1f08f15ab5643728469f9824e. In that cl I failed to pass flags coming from naked 'linker_flag' fields into legacy_link_flags. RELNOTES: None. PiperOrigin-RevId: 195131604
* RELNOTES: Save Blaze memory by not storing LinkerInput objects in ↵Gravatar Googler2018-05-02
| | | | | | LinkCommandLine PiperOrigin-RevId: 195099909
* Clean up code that directly imports nested classes like Builder, Entry, etc.Gravatar jcater2018-05-02
| | | | PiperOrigin-RevId: 195094385
* Automated rollback of commit 3fbe733bf72659e9de30fb099a65e87b1a402a18.Gravatar Googler2018-05-01
| | | | | | | | | | | | | | | | *** Reason for rollback *** Still causes a memory regression *** Original change description *** Consolidating start/end lib archive expansion Take 2 Different places in the link logic were in charge of expanding start/end lib archives, causing discrepancies. This CL gets rid of the special iteration in Link.java and makes LibrariesToLinkCollecter solely responsible for mapping static libraries to their object files on the link command l... RELNOTES: Fixing start/end lib expansion for linking. There were many cases where archive files were still being used with toolchains that support start/end lib. This change consolidates the places that make that decision so they can be more consistent. PiperOrigin-RevId: 194970156
* Consolidating start/end lib archive expansion Take 2Gravatar Googler2018-04-30
| | | | | | | | Different places in the link logic were in charge of expanding start/end lib archives, causing discrepancies. This CL gets rid of the special iteration in Link.java and makes LibrariesToLinkCollecter solely responsible for mapping static libraries to their object files on the link command l... RELNOTES: Fixing start/end lib expansion for linking. There were many cases where archive files were still being used with toolchains that support start/end lib. This change consolidates the places that make that decision so they can be more consistent. PiperOrigin-RevId: 194847987
* Automated rollback of commit fd9a0958a989cac1f08f15ab5643728469f9824e.Gravatar hlopko2018-04-30
| | | | | RELNOTES: None. PiperOrigin-RevId: 194746481
* Do not add flags from linking_mode_flags section when the toolchain definesGravatar hlopko2018-04-27
| | | | | | | | | | | | | | | | corresponding features. Therefore when both linking_mode_flags { mode: DYNAMIC } and feature { name: "dynamic_linking_mode" } are provided, bazel will only take flags from the feature. The same applies to mode: STATIC and static_linkin_mode feature respectively. mode: MOSTLY_STATIC_LIBRARIES is covered under dynamic_linking_mode for action "c++-link-dynamic-library". mode: FULLY_STATIC is handled separately. This is needed to provide a way of incremental migration towards legacy-flags-free crosstool. RELNOTES: None. PiperOrigin-RevId: 194556688
* Normalize parameter name commentsGravatar cushon2018-04-27
| | | | PiperOrigin-RevId: 194512971
* Automated rollback of commit 8ca66458a42266f11aba77732b05ab06b96e95fb.Gravatar hlopko2018-04-26
| | | | PiperOrigin-RevId: 194506134
* Consolidating start/end lib archive expansionGravatar Googler2018-04-26
| | | | | | | | Different places in the link logic were in charge of expanding start/end lib archives, causing discrepancies. This CL gets rid of the special iteration in Link.java and makes LibrariesToLinkCollecter solely responsible for mapping static libraries to their object files on the link command line. RELNOTES: Fixing start/end lib expansion for linking. There were many cases where archive files were still being used with toolchains that support start/end lib. This change consolidates the places that make that decision so they can be more consistent. PiperOrigin-RevId: 194400112
* Cleanup LibraryToLinkCollector to properly distinguish C++ runtimes from ↵Gravatar hlopko2018-04-24
| | | | | | | | | | | | | | | | dynamic libraries Term runtime input had 2 meanings in CppLinkAction: 1) input needed at runtime - dynamic library 2) input corresponding to the C++ runtime (libstdc++ or libc++) This confused me and therefore the code :) This cl cleans this up to some extent by: * renaming runtimeInput to runtimesInput, to at least give the reader a chance to catch the difference :) * treating runtimesInputs as normal linker inputs, also downstream in CppLinkAction and LinkCommandLine * Simplifying LibrariesToLinkCollector by removing explicit runtimesHandling. RELNOTES: None PiperOrigin-RevId: 194046439
* Optionally suppress ThinLTO indexing for all linkstatic targetsGravatar Googler2018-04-20
| | | | | | | | | | | | | | | This extends the scalability fix in https://github.com/bazelbuild/bazel/commit/8c5e290dfab3cab378a9ca107ecdd6267403cd4b to optionally apply to all statically linked targets. Some test invocations end up building non-testonly cc_binary that are in the transitive data deps of a test, and can lead to huge numbers of LTO backend jobs for those test invocations. With this change, the global blazerc can enable this feature for "blaze test". This can end up subsuming the thin_lto_linkstatic_tests_use_shared_nonlto_backends feature. However, it might be useful to keep that one as it can be the default for all blaze builds (in case anyone wants to just build and not run their tests). RELNOTES: None PiperOrigin-RevId: 193667161
* Make action_config.tools include crosstool top path by defaultGravatar hlopko2018-04-20
| | | | | | | | | | | We always prepend crosstool top path anyway, so let's create Tool instances with the already prepared path. I don't expect this affects memory usage since we don't have many cc_toolchain targets in the graph. RELNOTES: None PiperOrigin-RevId: 193660445
* Remove use of bare Immutable{List,Map,Set} Builder classes.Gravatar jcater2018-04-19
| | | | | | Always use the more-qualified class name for clarity at the site of use. There are too many classes named Builder. PiperOrigin-RevId: 193624381
* Clean up IterablesChain.Gravatar tomlu2018-04-18
| | | | | | | | | | | * Change builder return type to Iterable<T> instead of IterableChain<T>. It is over-specified and unnecessary to state the return type so precisely. * Optimize builder for cases where we add 0 or 1 iterables to the chain. In this case, we can simply return the underlying iterables without adding wrappers. * Extract DedupingIterable, it doesn't have anything to do with IterablesChain and is only used in one place RELNOTES: None PiperOrigin-RevId: 193363048
* Make statically linking cpp-runtimes as a crosstool feature.Gravatar Googler2018-04-12
| | | | | | | | | This cl should result in no user-visible change. It simply sets the feature based on the field in the crosstool proto. A subsequent cl will expose this feature for people to actually use. PiperOrigin-RevId: 192641438
* Remove traces of optional_flags from crosstoolGravatar hlopko2018-04-10
| | | | | | | AFAIK all uses have been migrated to features, so they are not needed anymore. RELNOTES: CppRules: optional_compiler_flag was removed from CROSSTOOL, use features instead. PiperOrigin-RevId: 192277764
* Automated rollback of commit 77c5582fa0f5c829df576d9f8d66f4975fe415a6.Gravatar hlopko2018-04-06
| | | | PiperOrigin-RevId: 191880445
* Make statically linking cpp-runtimes as a crosstool feature.Gravatar Googler2018-04-05
| | | | | | | | | | | This cl should result in no user-visible change. It simply sets the feature based on the field in the crosstool proto. A subsequent cl will expose this feature for people to actually use. DELTA_BY_EXTENSION=java=100,py=15 RELNOTES: None PiperOrigin-RevId: 191761838
* Isolate C++ link build variablesGravatar hlopko2018-04-03
| | | | | | | | | | | | | This is a preparation work to expose Variables instance for all link actions to Skylark. Compile build variables were done in https://github.com/bazelbuild/bazel/commit/31ab0b88ec52f293e713b9369ea4a706b6c0a57d. This is also in line with our goal to make build variables more discoverable and better document. RELNOTES: None. PiperOrigin-RevId: 191446799
* Isolate C++ compile build variablesGravatar hlopko2018-03-27
| | | | | | | | | | | | | | This is a preparation work to expose Variables instance for all compile actions to Skylark. I didn't do linking variables in this cl, because this cl is already too big. But they're coming shortly in a separate cl. This is also in line with our goal to make build variables more discoverable and better document. RELNOTES: None. PiperOrigin-RevId: 190591080
* Pass all TreeArtifacts to the ParameterWriteFileAction so they're expanded ↵Gravatar Googler2018-03-16
| | | | | | | | | | | by the time the action runs. Tested: custom_blaze build experimental/users/kmensah/cc_proto_library:libnon_android_example.so --config android_x86 -s RELNOTES: Properly handle tree artifacts on the link command line coming from a cc_library dependency. PiperOrigin-RevId: 189344192
* Suppress ThinLTO indexing for linkstatic library in testsGravatar Googler2018-03-15
| | | | | | | | | | This extends the scalability fix in https://github.com/bazelbuild/bazel/commit/8c5e290dfab3cab378a9ca107ecdd6267403cd4b to apply to statically linked libraries linked into dynamically linked tests. Otherwise we are still getting the O(N*M) LTO backend job behavior for those libraries when invoking ThinLTO on many targets. RELNOTES: None PiperOrigin-RevId: 189200150
* Support for passing options to LTO Backend actions onlyGravatar Googler2018-03-09
| | | | | | | | This is very useful for debugging and performance tuning. RELNOTES[NEW]: Adds --ltobackendopt and --per_file_ltobackendopt for passing options to ThinLTO LTO backend compile actions only. PiperOrigin-RevId: 188521075
* Cleanup linking input computation in CppLinkActionBuilderGravatar hlopko2018-03-05
| | | | | RELNOTES: None. PiperOrigin-RevId: 187855919
* Do not upload link inputs of the linkstamp compile actions to the executorGravatar hlopko2018-03-05
| | | | | | | | | | | | | | | | | Link inputs are there only to invalidate the action, they don't affect the execution of the compile action. This cl optimizes the action execution by not having to collect unnecessary inputs into the sandbox. Since this is CppCompileAction and nothing is easy here, let me elaborate on my assumptions. The goal of this cl is to stop passing unneeded inputs into Spawns. This is implemented by introducing a dispensableInputs field to the CppCompileAction. SpawnGccStrategy then doesn't forward these further. I'm not adding dispensableInputs to the ActionKey. I think it's enough to put them to the inputs and into the updateActionInputs method. RELNOTES: None. PiperOrigin-RevId: 187849482
* Introduce a specific action_config for linking nodeps dynamic librariesGravatar hlopko2018-03-01
| | | | | | | | | | | | | With this cl toolchain author can specify different flags for linking shared library produced by cc_library and a shared library produced by cc_binary. This is what is needed to remove linking_mode_flags - MOSTLY_STATIC_LIBRARIES from the crosstool. What this linking mode was used for was to separate when we link transitive shared library from cc_binary and when we link this little-and-not-really-useful-outside-of-bazel nodeps shared library in cc_library. RELNOTES: CcToolchain: Introduced action_config for "c++-link-transitive-dynamic-library" PiperOrigin-RevId: 187523334
* @AutoCodec CppLinkAction.Gravatar cpeyser2018-02-27
| | | | PiperOrigin-RevId: 187212799
* Hide fix for linkstmap inputs computation behind an optionGravatar hlopko2018-02-26
| | | | | | | | | | | This cl introduces a bazel option (--experimental_fix_linkstamp_inputs_bug_73447914) to control which inputs get added into C++ linkstamp compile action. When set to true (defaults to false), all inputs of relevant C++ linking action get added as inputs to the linkstamp compile action too. RELNOTES: None. PiperOrigin-RevId: 187030217
* Remove the CppConfiguration member from CppLinkAction. This will makeGravatar cpeyser2018-02-22
| | | | | | CppLinkAction more suitable for serialization. PiperOrigin-RevId: 186598828
* Recompile linkstamps whenever any input of the owning action changes.Gravatar hlopko2018-02-22
| | | | | | | | | | | Linkstamps were not re-built when only volatile data changed, i.e. when we modified cc_binary source, linkstamp was not recompiled so we got old timestamps. The proper behavior is to recompile linkstamp whenever any input to cc_binary linking action changes. And the implementation in this cl solves this by adding all linking inputs as inputs to linkstamp compile action. RELNOTES: None. PiperOrigin-RevId: 186595143
* Don't register linkstamp compile actions when we're doing thinlto indexing stepGravatar hlopko2018-02-21
| | | | | RELNOTES: None. PiperOrigin-RevId: 186456188
* Automated rollback of commit c7e343ad314aeab6283b5939bc8126a112140a11.Gravatar plf2018-02-16
| | | | | | | | | | | | | | | *** Reason for rollback *** Rolling back after having come up with a more principled solution in b/73047818 that will add a more generic attribute called additional_linker_inputs so that users can depend on any file of any type and reference it from linkopts. *** Original change description *** C++: Allows adding linkopts through file. The file can be generated during execution by a different rule. RELNOTES:none PiperOrigin-RevId: 185977745
* Add a CODEC for CppCompileAction.Gravatar cpeyser2018-02-14
| | | | PiperOrigin-RevId: 185733313
* Blaze: let a LinkerInput declare that it needs debug info in the executableGravatar Googler2018-02-12
| | | | | RELNOTES: None. PiperOrigin-RevId: 185455486
* C++: Allows adding linkopts through file.Gravatar plf2018-02-12
| | | | | | | The file can be generated during execution by a different rule. RELNOTES:none PiperOrigin-RevId: 185361140
* Suppress ThinLTO indexing for testonly targetsGravatar Googler2018-02-08
| | | | | | | | Applies ThinLTO scalability fix https://github.com/bazelbuild/bazel/commit/8c5e290dfab3cab378a9ca107ecdd6267403cd4b to targets (e.g. cc_binary) marked "testonly = 1". RELNOTES: None PiperOrigin-RevId: 184991176
* C++: Stops generating DWO files when PER_OBJECT_DEBUG_INFO feature is not ↵Gravatar plf2018-02-02
| | | | | | | enabled. RELNOTES:none PiperOrigin-RevId: 184303490
* Change how the libraries_to_link are expanded for archiverGravatar hlopko2018-02-02
| | | | | | | | | This makes object_file_group work correctly for archiving (So far object_file_group was only possible for linking, but with the introduction of tree artifact support, it can appear also for archiving). RELNOTES: Fix how libraries_to_link are expanded in the archiver command line. PiperOrigin-RevId: 184258745
* ThinLTO: Add support for merged object files.Gravatar Googler2018-01-23
| | | | | | | | | | | | | Merged object files are needed when we use -flto-unit. It's created during the LTO indexing step and needs to be passed to the final link. LLVM already can create merged object files we just need to pass "-Wl,-plugin-opt,obj-path=" into LLVM gold plugin. "-flto-unit" emits IR to support LTO unit features needed for CFI (Control Flow Integrity). RELNOTES: Add support for merged object files needed for -flto-unit. PiperOrigin-RevId: 182964781
* Non functional changes.Gravatar Googler2018-01-19
| | | | | | | | | | | Just shuffling code in the build() method to simplify future review. 1. Reuse result of getRootRelativePath() 2. Delay linkerInputs generation 3. allowLtoIndexing ? thinltoParamFile : null -> thinltoParamFile it must be null if indexing is not allowed RELNOTES: None PiperOrigin-RevId: 182626938
* C++: Fixes linkstamp not compiled with PIC.Gravatar plf2018-01-16
| | | | | RELNOTES:none PiperOrigin-RevId: 182044727
* RELNOTES: Allow expanding TreeArtifacts for libraries_to_linkGravatar Googler2018-01-12
| | | | PiperOrigin-RevId: 181750466
* Use more robust check for bitcode inputs to linkGravatar Googler2017-12-21
| | | | | | | | | | | | The current checks used in several places for whether an LTO indexing step is needed only looked for direct LTO bitcode inputs. Instead we should use the existing hasLtoBitcodeInputs() method to look both at the direct inputs as well as inputs on all LibraryToLink. This was already used in similar checking on the CppBinary. With this change, all places that test for needing an LTO indexing step use the correct interface. RELNOTES: None PiperOrigin-RevId: 179812972
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-07 11:10:58 +0000