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

add test for symbol visibility of #[naked] functions #128362

Merged
merged 1 commit into from
Aug 7, 2024

Conversation

folkertdev
Copy link
Contributor

@folkertdev folkertdev commented Jul 29, 2024

tracking issue: #90957

This test is extracted from #128004

That PR attempts to generated naked functions as an extern function declaration, combined with a global asm block that provides the implementation for that declaration.

In order to link declaration and definition together, some flavor of external linking must be used: LLVM will error for other linkage types. Specifically the allowed options are #[linkage = "external"] and #[linkage = "extern_weak"]. That is kind of an implementation detail though: to the user, a naked function should just behave like a normal function.

Hence it should be visible to the linker under the same circumstances as a normal, vanilla function and have the same attributes (Weak, External). Getting this behavior right will require some care, so I think it's a good idea to lock it in now, before making any changes, to make sure we don't regress.

Are there any interesting cases that I missed here? E.g. is checking on different architectures worth it? I don't think the other binary types (rlib etc) are relevant here, but may be missing something.

r? @bjorn3

@rustbot rustbot added A-run-make Area: port run-make Makefiles to rmake.rs S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 29, 2024
@rustbot
Copy link
Collaborator

rustbot commented Jul 29, 2024

This PR modifies tests/run-make/. If this PR is trying to port a Makefile
run-make test to use rmake.rs, please update the
run-make port tracking issue
so we can track our progress. You can either modify the tracking issue
directly, or you can comment on the tracking issue and link this PR.

cc @jieyouxu

@tgross35
Copy link
Contributor

Do we already have a test for global? If not, it might be worth adding one.

@folkertdev
Copy link
Contributor Author

Do we already have a test for global? If not, it might be worth adding one.

global what? I don't understand what you're suggesting here.

@tgross35
Copy link
Contributor

I was suggesting that you might as well add a check for global_asm! in this new rmake test, since it doesn't look like we have something for that currently. I.e. something that tests the current behavior of #128071.

@folkertdev folkertdev force-pushed the naked-function-symbol-visibility branch 2 times, most recently from 8040197 to 940a109 Compare August 3, 2024 16:09
@folkertdev
Copy link
Contributor Author

now updated to match the style of #128607 (the aim there is to not use llvm CLI tools, which is a good idea)

@bjorn3
Copy link
Member

bjorn3 commented Aug 3, 2024

@bors r+

@bors
Copy link
Contributor

bors commented Aug 3, 2024

📌 Commit 940a109 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 Aug 3, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Aug 4, 2024
…isibility, r=bjorn3

add test for symbol visibility of `#[naked]` functions

tracking issue: rust-lang#90957

This test is extracted from rust-lang#128004

That PR attempts to generated naked functions as an extern function declaration, combined with a global asm block that provides the implementation for that declaration.

In order to link declaration and definition together, some flavor of external linking must be used: LLVM will error for other linkage types. Specifically the allowed options are `#[linkage = "external"]` and `#[linkage = "extern_weak"]`. That is kind of an implementation detail though: to the user, a naked function should just behave like a normal function.

Hence it should be visible to the linker under the same circumstances as a normal, vanilla function and have the same attributes (Weak, External). Getting this behavior right will require some care, so I think it's a good idea to lock it in now, before making any changes, to make sure we don't regress.

Are there any interesting cases that I missed here? E.g. is checking on different architectures worth it? I don't think the other binary types (rlib etc) are relevant here, but may be missing something.

r? `@bjorn3`
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 4, 2024
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#128305 (improve error message when `global_asm!` uses `asm!` operands)
 - rust-lang#128362 (add test for symbol visibility of `#[naked]` functions)
 - rust-lang#128526 (time.rs: remove "Basic usage text")
 - rust-lang#128531 (Miri: add a flag to do recursive validity checking)
 - rust-lang#128589 (allow setting `link-shared` and `static-libstdcpp` with CI LLVM)
 - rust-lang#128615 (rustdoc: make the hover trail for doc anchors a bit bigger)
 - rust-lang#128620 (Update rinja version to 0.3.0)

r? `@ghost`
`@rustbot` modify labels: rollup
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Aug 4, 2024
…isibility, r=bjorn3

add test for symbol visibility of `#[naked]` functions

tracking issue: rust-lang#90957

This test is extracted from rust-lang#128004

That PR attempts to generated naked functions as an extern function declaration, combined with a global asm block that provides the implementation for that declaration.

In order to link declaration and definition together, some flavor of external linking must be used: LLVM will error for other linkage types. Specifically the allowed options are `#[linkage = "external"]` and `#[linkage = "extern_weak"]`. That is kind of an implementation detail though: to the user, a naked function should just behave like a normal function.

Hence it should be visible to the linker under the same circumstances as a normal, vanilla function and have the same attributes (Weak, External). Getting this behavior right will require some care, so I think it's a good idea to lock it in now, before making any changes, to make sure we don't regress.

Are there any interesting cases that I missed here? E.g. is checking on different architectures worth it? I don't think the other binary types (rlib etc) are relevant here, but may be missing something.

r? ``@bjorn3``
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 4, 2024
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#128362 (add test for symbol visibility of `#[naked]` functions)
 - rust-lang#128526 (time.rs: remove "Basic usage text")
 - rust-lang#128531 (Miri: add a flag to do recursive validity checking)
 - rust-lang#128578 (rustdoc: Cleanup `CacheBuilder` code for building search index)
 - rust-lang#128589 (allow setting `link-shared` and `static-libstdcpp` with CI LLVM)
 - rust-lang#128615 (rustdoc: make the hover trail for doc anchors a bit bigger)
 - rust-lang#128620 (Update rinja version to 0.3.0)

r? `@ghost`
`@rustbot` modify labels: rollup
@matthiaskrgr
Copy link
Member

@bors r- .. ^^

@bors bors 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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 4, 2024
@folkertdev folkertdev force-pushed the naked-function-symbol-visibility branch from 940a109 to 5ee6701 Compare August 4, 2024 09:40
@folkertdev
Copy link
Contributor Author

that typo has now been resolved (and the commits squashed)

@rustbot ready (we could try a try action though?)

@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 Aug 4, 2024
@bjorn3
Copy link
Member

bjorn3 commented Aug 4, 2024

I don't think a try build is necessary for now. If it fails again, a try build may be worthwhile.

@bors r+

@bors bors added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 4, 2024
@folkertdev
Copy link
Contributor Author

so, not even #[no_mangle] pub symbols are actually in the dynamic symbol table of a cdylib with msvc???

--- stderr -------------------------------
thread 'main' panicked at C:\a\rust\rust\tests\run-make\naked-symbol-visibility\rmake.rs:18:5:
thread 'main' panicked at C:\a\rust\rust\tests\run-make\naked-symbol-visibility\rmake.rs:18:5:
symbol public_vanilla occurs 0 times

@ChrisDenton I don't think this does much different to the tests/run-make/symbol-visibility/rmake.rs test, except that that uses exports and not dynamic_symbols that I need here to get some extra data on the symbols. Does dynamic_symbols just not work with msvc? it seems to do fine with x86_64-pc-windows-gnu (which I guess runs under wine on my linux machine)

@ChrisDenton
Copy link
Member

ChrisDenton commented Aug 5, 2024

According to Object::dynamic_symbols.

Only ELF has dynamic linking symbols. Other file formats will return an empty iterator. Consider using Self::exports or Self::imports instead.

I'm not sure why it would work with windows-gnu.

@folkertdev
Copy link
Contributor Author

hmm okay, weird. even based on the source that really should not work on any windows target.

I guess I can filter symbols() by whether they occur in exports() and see if that works out.

@folkertdev folkertdev force-pushed the naked-function-symbol-visibility branch from d7ddc3a to ee43eef Compare August 5, 2024 14:51
@jieyouxu
Copy link
Member

jieyouxu commented Aug 5, 2024

@bors try

bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 5, 2024
…ibility, r=<try>

add test for symbol visibility of `#[naked]` functions

tracking issue: rust-lang#90957

This test is extracted from rust-lang#128004

That PR attempts to generated naked functions as an extern function declaration, combined with a global asm block that provides the implementation for that declaration.

In order to link declaration and definition together, some flavor of external linking must be used: LLVM will error for other linkage types. Specifically the allowed options are `#[linkage = "external"]` and `#[linkage = "extern_weak"]`. That is kind of an implementation detail though: to the user, a naked function should just behave like a normal function.

Hence it should be visible to the linker under the same circumstances as a normal, vanilla function and have the same attributes (Weak, External). Getting this behavior right will require some care, so I think it's a good idea to lock it in now, before making any changes, to make sure we don't regress.

Are there any interesting cases that I missed here? E.g. is checking on different architectures worth it? I don't think the other binary types (rlib etc) are relevant here, but may be missing something.

r? `@bjorn3`

try-job: x86_64-msvc
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-mingw
@bors
Copy link
Contributor

bors commented Aug 5, 2024

⌛ Trying commit ee43eef with merge 0280c59...

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Aug 5, 2024

💔 Test failed - checks-actions

@folkertdev
Copy link
Contributor Author

well:

thread 'main' panicked at C:\a\rust\rust\tests\run-make\naked-symbol-visibility\rmake.rs:18:5:
symbol public_vanilla occurs 0 times
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

so, I'd propose to skip msvc, maybe all of windows, for now?

@folkertdev folkertdev force-pushed the naked-function-symbol-visibility branch from ee43eef to 3462e45 Compare August 5, 2024 17:40
Copy link
Contributor Author

@folkertdev folkertdev left a comment

Choose a reason for hiding this comment

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

I've added //@ only-linux, which combined with //@ only-x86_64

@bjorn3
Copy link
Member

bjorn3 commented Aug 5, 2024

Can you use //@ ignore-windows instead? I don't see any reason why it shouldn't work on say FreeBSD or arm64.

@folkertdev folkertdev force-pushed the naked-function-symbol-visibility branch from 3462e45 to 1967951 Compare August 5, 2024 17:55
@@ -0,0 +1,98 @@
//@ ignore-windows
//@ only-x86_64
Copy link
Member

Choose a reason for hiding this comment

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

Is the only-x86_64 really necessary?

Copy link
Contributor Author

@folkertdev folkertdev Aug 5, 2024

Choose a reason for hiding this comment

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

yes, the inline/global assembly will break on aarch64 right?

Copy link
Member

Choose a reason for hiding this comment

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

Right

@bjorn3
Copy link
Member

bjorn3 commented Aug 5, 2024

@bors r+

@bors
Copy link
Contributor

bors commented Aug 5, 2024

📌 Commit 1967951 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 5, 2024
tgross35 added a commit to tgross35/rust that referenced this pull request Aug 7, 2024
…isibility, r=bjorn3

add test for symbol visibility of `#[naked]` functions

tracking issue: rust-lang#90957

This test is extracted from rust-lang#128004

That PR attempts to generated naked functions as an extern function declaration, combined with a global asm block that provides the implementation for that declaration.

In order to link declaration and definition together, some flavor of external linking must be used: LLVM will error for other linkage types. Specifically the allowed options are `#[linkage = "external"]` and `#[linkage = "extern_weak"]`. That is kind of an implementation detail though: to the user, a naked function should just behave like a normal function.

Hence it should be visible to the linker under the same circumstances as a normal, vanilla function and have the same attributes (Weak, External). Getting this behavior right will require some care, so I think it's a good idea to lock it in now, before making any changes, to make sure we don't regress.

Are there any interesting cases that I missed here? E.g. is checking on different architectures worth it? I don't think the other binary types (rlib etc) are relevant here, but may be missing something.

r? `@bjorn3`
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 7, 2024
Rollup of 7 pull requests

Successful merges:

 - rust-lang#128107 (Migrate `raw-dylib-alt-calling-convention`, `raw-dylib-c` and `redundant-libs` `run-make` tests to rmake)
 - rust-lang#128362 (add test for symbol visibility of `#[naked]` functions)
 - rust-lang#128417 (Add `f16` and `f128` math functions)
 - rust-lang#128638 (run-make: enable msvc for `link-dedup`)
 - rust-lang#128647 (Enable msvc for link-args-order)
 - rust-lang#128649 (run-make: Enable msvc for `no-duplicate-libs` and `zero-extend-abi-param-passing`)
 - rust-lang#128766 (Trivial grammar fix in const keyword docs)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 7, 2024
Rollup of 7 pull requests

Successful merges:

 - rust-lang#128107 (Migrate `raw-dylib-alt-calling-convention`, `raw-dylib-c` and `redundant-libs` `run-make` tests to rmake)
 - rust-lang#128362 (add test for symbol visibility of `#[naked]` functions)
 - rust-lang#128417 (Add `f16` and `f128` math functions)
 - rust-lang#128638 (run-make: enable msvc for `link-dedup`)
 - rust-lang#128647 (Enable msvc for link-args-order)
 - rust-lang#128649 (run-make: Enable msvc for `no-duplicate-libs` and `zero-extend-abi-param-passing`)
 - rust-lang#128766 (Trivial grammar fix in const keyword docs)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 7, 2024
Rollup of 7 pull requests

Successful merges:

 - rust-lang#128107 (Migrate `raw-dylib-alt-calling-convention`, `raw-dylib-c` and `redundant-libs` `run-make` tests to rmake)
 - rust-lang#128362 (add test for symbol visibility of `#[naked]` functions)
 - rust-lang#128417 (Add `f16` and `f128` math functions)
 - rust-lang#128638 (run-make: enable msvc for `link-dedup`)
 - rust-lang#128647 (Enable msvc for link-args-order)
 - rust-lang#128649 (run-make: Enable msvc for `no-duplicate-libs` and `zero-extend-abi-param-passing`)
 - rust-lang#128766 (Trivial grammar fix in const keyword docs)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 10a7f93 into rust-lang:master Aug 7, 2024
6 checks passed
@rustbot rustbot added this to the 1.82.0 milestone Aug 7, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Aug 7, 2024
Rollup merge of rust-lang#128362 - folkertdev:naked-function-symbol-visibility, r=bjorn3

add test for symbol visibility of `#[naked]` functions

tracking issue: rust-lang#90957

This test is extracted from rust-lang#128004

That PR attempts to generated naked functions as an extern function declaration, combined with a global asm block that provides the implementation for that declaration.

In order to link declaration and definition together, some flavor of external linking must be used: LLVM will error for other linkage types. Specifically the allowed options are `#[linkage = "external"]` and `#[linkage = "extern_weak"]`. That is kind of an implementation detail though: to the user, a naked function should just behave like a normal function.

Hence it should be visible to the linker under the same circumstances as a normal, vanilla function and have the same attributes (Weak, External). Getting this behavior right will require some care, so I think it's a good idea to lock it in now, before making any changes, to make sure we don't regress.

Are there any interesting cases that I missed here? E.g. is checking on different architectures worth it? I don't think the other binary types (rlib etc) are relevant here, but may be missing something.

r? ``@bjorn3``
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-run-make Area: port run-make Makefiles to rmake.rs S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

9 participants