Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support the rustc metadata for AIX #107583

Merged
merged 2 commits into from
Jun 5, 2023
Merged

Conversation

EsmeYi
Copy link
Contributor

@EsmeYi EsmeYi commented Feb 2, 2023

Support the rustc metadata for rlibs and dylibs on AIX.
XCOFF is the object file format on AIX.

@rustbot
Copy link
Collaborator

rustbot commented Feb 2, 2023

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Nilstrieb (or someone else) soon.

Please see the contribution instructions for more information.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 2, 2023
@Noratrieb
Copy link
Member

Marking was waiting-on-author as it currently doesn't build and seems to require upstream changes in object first.
@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 2, 2023
@@ -93,6 +101,27 @@ pub(super) fn search_for_section<'a>(
.map_err(|e| format!("failed to read {} section in '{}': {}", section, path.display(), e))
}

pub(super) fn get_metadata_xcoff<'a>(path: &Path, data: &'a [u8]) -> Result<&'a [u8], String> {
let buf = search_for_section(path, data, ".info")?;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do we know that the first entry in the .info section is our metadata? Are we sure that rustc is the only source of data in .info? According to the documentation, we should be using a symbol to locate it instead:

The n_name field is preserved by the binder. An application-defined unique name in this field can be used to filter access to only those comment section strings intended for the application.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some object files, multiple segments may contain sections with the same name. However as I know, with XCOFF there may be multiple sections with type info, but their names must be different. Therefore, the ".info" section can be specific for metadata.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that .info may contain multiple comments, and we need to use a symbol to locate the comment in .info that rustc added.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see.
We've added a symbol with value of 4, which specifies the offset in comment section, to refer to the rust metadata.

    // Add a symbol referring to .info section.
    // Storage class will be handled in object crate.
    file.add_symbol(Symbol {
        name: "info".into(),
        value: 4,
        size: 0,
        kind: SymbolKind::Unknown,
        scope: SymbolScope::Dynamic,
        weak: false,
        section: SymbolSection::Section(section),
        flags: SymbolFlags::Xcoff { n_sclass : xcoff::C_INFO },
    });

Do you mean that we should use the value in the symbol to locate the metadata instead of reading the first entry directly? In the meanwhile, we can change the name 'info' to 'rustc' to make the symbol be the identifier?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the documentation, yes.

// Add a symbol referring to .info section.
// Storage class will be handled in object crate.
file.add_symbol(Symbol {
name: "info".into(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this should be the identifier that we use for section names in other formats (.rmeta and .rustc).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the .rustc section the symbol has a unique name derived from the crate hash I believe.

name: "info".into(),
value: 4,
size: 0,
kind: object::SymbolKind::Null,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change to SymbolKind::Unknown and use SymbolFlags::Xcoff to set this to C_INFO.

b".info".to_vec(),
SectionKind::Debug,
);
file.add_file_symbol(".file".into());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The documentation says that .file is used when there is a file auxiliary symbol. Ideally all handling of .file would be internal to the object crate, so here we would specify the actual file name we want.

@workingjubilee workingjubilee added the O-aix OS: Big Blue's Advanced Interactive eXecutive.. label Feb 5, 2023
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@@ -60,16 +60,24 @@ impl MetadataLoader for DefaultMetadataLoader {
let data = entry
.data(data)
.map_err(|e| format!("failed to parse rlib '{}': {}", path.display(), e))?;
return search_for_section(path, data, ".rmeta");
if target.is_like_aix {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though xcoff is bound to AIX, I think checking the format is more precise.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have format info in this function. While according to your comments, I changed such checks in fn create_wrapper_file() and fn create_compressed_metadata_file(). Thanks.

fn get_dylib_metadata(&self, _target: &Target, path: &Path) -> Result<MetadataRef, String> {
load_metadata_with(path, |data| search_for_section(path, data, ".rustc"))
fn get_dylib_metadata(&self, target: &Target, path: &Path) -> Result<MetadataRef, String> {
if target.is_like_aix {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dito

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.

compiler/rustc_codegen_ssa/src/back/metadata.rs Outdated Show resolved Hide resolved
let buf = search_for_section(path, data, ".info")?;
let offset = file.symbol_address_by_name("rustc")?;
// The first 4 bytes from offset are length field for rustc metadata.
if offset + 4 >= buf.len() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be handled by object crate. For AIX toolchain, a C_INFO symbol's offset inside .info section doesn't count the first 4-bytes length field. When reading the object file, we can set C_INFO ObjectSymbol's address the offset into .info section and the size can be initialized from the first 4-bytes length field.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be handled by object crate.

I think it will be a little wired if we add an interface in https://github.com/gimli-rs/object/blob/master/src/read/traits.rs, which is specific for XCOFF platform.

@rust-log-analyzer

This comment has been minimized.

@EsmeYi EsmeYi marked this pull request as draft April 12, 2023 02:43
@rust-log-analyzer

This comment has been minimized.

@EsmeYi
Copy link
Contributor Author

EsmeYi commented Apr 18, 2023

The PR is expected to pass CI checks after the release of the new version of Object crate https://github.com/gimli-rs/object which may include features of writing a XCOFF object file.
Hi @philipc, what is your plan to release a new version of Object?

@philipc
Copy link
Contributor

philipc commented Apr 18, 2023

Sorry I forgot to tell you. A new version was released a few days ago.

@EsmeYi
Copy link
Contributor Author

EsmeYi commented Apr 20, 2023

hi @bjorn3, could you help to updates object to 0.31.0 for ar_archive_writer and thorin-dwp? Thanks!

@ecnelises
Copy link
Contributor

I posted PR to bump object in rust-lang/ar_archive_writer#6. And I see @philipc has one for thorin: rust-lang/thorin#24.

/// From XCOFF's view, (2) creates a csect entry in the symbol table, the
/// symbol created by (3) is a info symbol for the preceding csect. Thus
/// two symbols are preserved during linking and we can use the second symbol
/// to reference the metadata.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two kinds of object files created. One (create_wrapper_file) is for use in rlibs and we do not want to preserve metadata in there. It is only wrapped in an rlib to prevent linkers from complaining about files that are not valid object files in archives. The other kind (create_compressed_metadata_file) contains compressed metadata and is used for rust dylibs. This one should be preserved.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AIX linker will abort if it finds lib.rmeta is a valid XCOFF file but only has .info section (no .bss, .data or .text). Fortunately, we can just add a stub .text section to make linker happy:

file.add_section(Vec::new(), b".text".to_vec(), SectionKind::Text);

@rust-log-analyzer

This comment has been minimized.

@ecnelises
Copy link
Contributor

backtrace uses object 0.30, maybe due to some inconsistency between 0.30 and 0.31? If so, we have to also bump object to 0.31.0 in backtrace (rust-lang/backtrace-rs#522 )

@@ -27,10 +27,10 @@ addr2line = { version = "0.19.0", optional = true, default-features = false }
rustc-demangle = { version = "0.1.21", features = ['rustc-dep-of-std'] }
miniz_oxide = { version = "0.6.0", optional = true, default-features = false }
[dependencies.object]
version = "0.30.0"
version = "0.31.0"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it build without this change? backtrace-rs doesn't have xcoff support yet anyway.

@bors
Copy link
Contributor

bors commented Apr 30, 2023

☔ The latest upstream changes (presumably #111001) made this pull request unmergeable. Please resolve the merge conflicts.

@rust-log-analyzer

This comment has been minimized.

@philipc
Copy link
Contributor

philipc commented May 11, 2023

object is being bumped in #111413

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@EsmeYi EsmeYi marked this pull request as ready for review May 23, 2023 09:07
Copy link
Contributor

@bzEq bzEq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@EsmeYi
Copy link
Contributor Author

EsmeYi commented May 31, 2023

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 31, 2023
@Noratrieb
Copy link
Member

r? @bjorn3
Sorry for not swapping earlier

@rustbot rustbot assigned bjorn3 and unassigned Noratrieb May 31, 2023
@bjorn3
Copy link
Member

bjorn3 commented Jun 5, 2023

@bors r+

@bors
Copy link
Contributor

bors commented Jun 5, 2023

📌 Commit e31661c has been approved by bjorn3

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 5, 2023
@bors
Copy link
Contributor

bors commented Jun 5, 2023

⌛ Testing commit e31661c with merge 7452822...

@bors
Copy link
Contributor

bors commented Jun 5, 2023

☀️ Test successful - checks-actions
Approved by: bjorn3
Pushing 7452822 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 5, 2023
@bors bors merged commit 7452822 into rust-lang:master Jun 5, 2023
@rustbot rustbot added this to the 1.72.0 milestone Jun 5, 2023
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (7452822): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-1.9% [-1.9%, -1.9%] 1
All ❌✅ (primary) - - 0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-4.9% [-5.3%, -4.5%] 4
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 646.615s -> 646.59s (-0.00%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. O-aix OS: Big Blue's Advanced Interactive eXecutive.. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.