BaseTools/build_rule.template: Set additional Rust module linker flags #1098
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This change sets the ImageBase in the PE header for Rust modules to `0` so they do not have a preferred base. This is similar to the EFI images produced by the edk2 build system. The subsystem type is also set to `efi_boot_service_driver` instead of the default target specification value of `EFI_APPLICATION`. Details for changing the subsystem type are here: https://doc.rust-lang.org/nightly/rustc/platform-support/unknown-uefi.html#requirements Ideally, these values would be set as individual `target.<triple>.rustflags` in `.cargo/config.toml`. However, we override the `/MAP` argument using `-C linker-args` in `build_rule.txt` to the build output directory. This must be set dynamically since the output directory and module name are based on per module values. Since the cargo configuration file does not support reading environment variables and setting an environment there in a `[env]` section would be too late to impact the commands that run in `build_rules.txt` (cargo is called from cargo make based on those rules), this is the simplest approach to retain the map file path in addition to the new changes. In the future, this may be moved to a common target specification so the values are available without these changes. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
github-actions
bot
added
impact:breaking-change
Javagedes
approved these changes
Aug 8, 2024
vineelko
approved these changes
Aug 8, 2024
apop5
approved these changes
Aug 8, 2024
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## release/202311 #1098 +/- ##
==================================================
+ Coverage 1.06% 1.35% +0.28%
==================================================
Files 1303 1303
Lines 332238 333838 +1600
Branches 5103 5103
==================================================
+ Hits 3547 4512 +965
- Misses 328204 329243 +1039
+ Partials 487 83 -404
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
5 tasks
makubacki
added a commit
to makubacki/mu_basecore
that referenced
this pull request
Aug 9, 2024
microsoft#1098) ## Description This change sets the ImageBase in the PE header for Rust modules to `0` so they do not have a preferred base. This is similar to the EFI images produced by the edk2 build system. The subsystem type is also set to `efi_boot_service_driver` instead of the default target specification value of `EFI_APPLICATION`. Details for changing the subsystem type are here: https://doc.rust-lang.org/nightly/rustc/platform-support/unknown-uefi.html#requirements Ideally, these values would be set as individual `target.<triple>.rustflags` in `.cargo/config.toml`. However, we override the `/MAP` argument using `-C linker-args` in `build_rule.txt` to the build output directory. This must be set dynamically since the output directory and module name are based on per module values. Since the cargo configuration file does not support reading environment variables and setting an environment there in a `[env]` section would be too late to impact the commands that run in `build_rules.txt` (cargo is called from cargo make based on those rules), this is the simplest approach to retain the map file path in addition to the new changes. In the future, this may be moved to a common target specification so the values are available without these changes. - [ ] Impacts functionality? - [ ] Impacts security? - [x] Breaking change? - [ ] Includes tests? - [ ] Includes documentation? ## How This Was Tested - Checked `ImageBase` and `Subsystem` of EFI images in output directory to confirm expected values. ## Integration Instructions This change is marked as breaking in case flows were dependent on the previous behavior. Otherwise, no changes are nedeed. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
5 tasks
makubacki
added a commit
that referenced
this pull request
Aug 9, 2024
#1098) ## Description This change sets the ImageBase in the PE header for Rust modules to `0` so they do not have a preferred base. This is similar to the EFI images produced by the edk2 build system. The subsystem type is also set to `efi_boot_service_driver` instead of the default target specification value of `EFI_APPLICATION`. Details for changing the subsystem type are here: https://doc.rust-lang.org/nightly/rustc/platform-support/unknown-uefi.html#requirements Ideally, these values would be set as individual `target.<triple>.rustflags` in `.cargo/config.toml`. However, we override the `/MAP` argument using `-C linker-args` in `build_rule.txt` to the build output directory. This must be set dynamically since the output directory and module name are based on per module values. Since the cargo configuration file does not support reading environment variables and setting an environment there in a `[env]` section would be too late to impact the commands that run in `build_rules.txt` (cargo is called from cargo make based on those rules), this is the simplest approach to retain the map file path in addition to the new changes. In the future, this may be moved to a common target specification so the values are available without these changes. - [ ] Impacts functionality? - [ ] Impacts security? - [x] Breaking change? - [ ] Includes tests? - [ ] Includes documentation? ## How This Was Tested - Checked `ImageBase` and `Subsystem` of EFI images in output directory to confirm expected values. ## Integration Instructions This change is marked as breaking in case flows were dependent on the previous behavior. Otherwise, no changes are nedeed. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This change sets the ImageBase in the PE header for Rust modules to
0so they do not have a preferred base. This is similar to the EFI images produced by the edk2 build system. The subsystem type is also set toefi_boot_service_driverinstead of the default target specification value ofEFI_APPLICATION. Details for changing the subsystem type are here:https://doc.rust-lang.org/nightly/rustc/platform-support/unknown-uefi.html#requirements
Ideally, these values would be set as individual
target.<triple>.rustflagsin.cargo/config.toml. However, we override the/MAPargument using-C linker-argsinbuild_rule.txtto the build output directory. This must be set dynamically since the output directory and module name are based on per module values.Since the cargo configuration file does not support reading environment variables and setting an environment there in a
[env]section would be too late to impact the commands that run inbuild_rules.txt(cargo is called from cargo make based on those rules), this is the simplest approach to retain the map file path in addition to the new changes.In the future, this may be moved to a common target specification so the values are available without these changes.
How This Was Tested
ImageBaseandSubsystemof EFI images in output directoryto confirm expected values.
Integration Instructions
This change is marked as breaking in case flows were dependent on the
previous behavior. Otherwise, no changes are nedeed.