Fixes PR39799
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 28607 Build 28606: arc lint + arc unit
Event Timeline
So after some further digging I was wrong, and my particular bug isn't to do with S->kind(). :(
The function that I'm interested in (a Rust function, on arm64, if it matters) is apparently failing the IMAGE_SYM_DTYPE_FUNCTION test. Is there any other category of thing that it could be?
The function that I'm interested in (a Rust function, on arm64, if it matters) is apparently failing the IMAGE_SYM_DTYPE_FUNCTION test. Is there any other category of thing that it could be?
Its getType() is 0, if that means anything.
lld/test/COFF/guardcf-thunk.s | ||
---|---|---|
28 | I think IMAGE_SYM_DTYPE_FUNCTION is set by the .type directive in this .def/.endef block. I guess what we're doing doesn't match MSVC, but it also seems reasonable. Is the Rust function written in assembly, or is it emitted in LLVM? We should be setting the appropriate type... |
lld/test/COFF/guardcf-thunk.s | ||
---|---|---|
28 | The function is on_tls_callback at https://github.com/rust-lang/rust/blob/master/src/libstd/sys/windows/thread_local.rs#L201. (It's unclear to me if the linker magic related to TLS callbacks is related to this issue. This is just the first function we fail at. I don't know if there are more "normal" functions that we'd fail on after it.) |
lld/test/COFF/guardcf-thunk.s | ||
---|---|---|
28 | Well, most global variables also seem to have type "notype", so the only way we could make this work is by dropping the symbol type check completely and just looking at the section executability. |
lld/test/COFF/guardcf-thunk.s | ||
---|---|---|
28 | I checked, and MSVC performs this symbol type check, so we are being compatible, and I don't think we should remove it. |
Oh you know what, I bet it's https://reviews.llvm.org/D53540#1326473. Rust has an LLVM roll in progress as I write this, so this should just sort itself out.
Sorry for making you write a "needless" patch, though I'm glad that at least the original bug you filed is fixed!
I think IMAGE_SYM_DTYPE_FUNCTION is set by the .type directive in this .def/.endef block. I guess what we're doing doesn't match MSVC, but it also seems reasonable. Is the Rust function written in assembly, or is it emitted in LLVM? We should be setting the appropriate type...