Skip to content

Implement current_dll_path for AIX #109522

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

Merged
merged 4 commits into from
Mar 31, 2023
Merged

Conversation

bzEq
Copy link
Contributor

@bzEq bzEq commented Mar 23, 2023

AIX doesn't feature dladdr, use loadquery instead.

loadquery is documented in https://www.ibm.com/docs/en/aix/7.2?topic=l-loadquery-subroutine.

@rustbot
Copy link
Collaborator

rustbot commented Mar 23, 2023

r? @cjgillot

(rustbot has picked a reviewer for you, use r? to override)

@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 Mar 23, 2023
#[cfg(target_os = "aix")]
unsafe {
let addr = current_dll_path as u64;
let mut buffer = vec![0i8; 4096];
Copy link
Member

@Noratrieb Noratrieb Mar 23, 2023

Choose a reason for hiding this comment

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

This may not be properly aligned for ld_info (it probably will in practice but we shouldn't rely on it). You should use a vec![std::mem::zeroed::<libc::ld_info>(); N] instead (and make sure to properly translate the length when calling loadquery).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a good point.

@faptc
Copy link

faptc commented Mar 23, 2023

You could use MaybeUninit as a field in an aligned struct instead. With the alignment is the same as ld_info's.
Also you might prefer using ptr::raw to get the raw pointers to avoid accidently creating unaligned references.

@cjgillot
Copy link
Contributor

r? @Nilstrieb

@rustbot rustbot assigned Noratrieb and unassigned cjgillot Mar 23, 2023
@bzEq bzEq requested a review from Noratrieb March 24, 2023 02:34
@Noratrieb Noratrieb 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 Mar 24, 2023
@bzEq bzEq requested a review from Noratrieb March 28, 2023 02:51
Copy link
Member

@Noratrieb Noratrieb left a comment

Choose a reason for hiding this comment

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

Thanks for adding the extra context around function descriptors, I wasn't aware of that.

After addressing my comment, have you tested the change? We can't really add a test ourselves and I don't have access to an AIX machine, but it would nice if you could test it to make sure that it works.

loop {
let text_base = (*current).ldinfo_textorg as u64;
let text_end = text_base + (*current).ldinfo_textsize;
if (text_base..text_end).contains(&addr) {
Copy link
Member

Choose a reason for hiding this comment

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

The function descriptor lives in the data and not text segment, doesn't it? So we should look in there instead of text. (I wasn't aware of AIX function descriptors when I made the first comment asking why it would be in data).

Copy link
Contributor Author

@bzEq bzEq Mar 28, 2023

Choose a reason for hiding this comment

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

Yes, the function descriptor lives in the data segment. In this context, the correctness should be the same for either using text or data segment. For sure, I'll update to use data segment which is less surprising than deferencing from the function descriptor.

@bzEq
Copy link
Contributor Author

bzEq commented Mar 28, 2023

After addressing my comment, have you tested the change? We can't really add a test ourselves and I don't have access to an AIX machine, but it would nice if you could test it to make sure that it works.

Yes, I tested it via bootstrapping stage2 rustc.

@bzEq bzEq requested a review from Noratrieb March 28, 2023 09:53
@bzEq bzEq force-pushed the aix-current-dll-path branch from eb122bf to 49f63eb Compare March 28, 2023 09:54
@Noratrieb
Copy link
Member

@bors r+

@bors
Copy link
Collaborator

bors commented Mar 28, 2023

📌 Commit 49f63eb has been approved by Nilstrieb

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 28, 2023
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 30, 2023
…mpiler-errors

Rollup of 6 pull requests

Successful merges:

 - rust-lang#109347 (Skip no_mangle if the item has no name.)
 - rust-lang#109522 (Implement current_dll_path for AIX)
 - rust-lang#109679 (Freshen normalizes-to hack goal RHS in the evaluate loop)
 - rust-lang#109704 (resolve: Minor improvements to effective visibilities)
 - rust-lang#109739 (Closures always implement `FnOnce` in new solver)
 - rust-lang#109758 (Parallel compiler cleanups)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit bc7976e into rust-lang:master Mar 31, 2023
@rustbot rustbot added this to the 1.70.0 milestone Mar 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

6 participants