DllMain is never run when given stdcall decorated export #135188
Labels
C-bug
Category: This is a bug.
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
O-windows
Operating system: Windows
I'm creating a Windows DLL in an admittedly goofy fashion: I have an executable that links a DLL and imports
DllMain
, using stdcall decorations (so in reality it's looking for_DllMain@12
). This causes the DllMain function to not actually run when the DLL is linked. I made a dummy DllMain function that just returnsfalse
to prevent the linking program from running, making it obvious that my code is running, but the program is starting successfully. It's worth noting that I'm running into this when testing out replacing a C DLL with a new, Rust-based DLL. My C version natively exports_DllMain@12
Using the common wisdom of using
#[no_mangle]
onDllMain
, it is failing to link with my executable because it does not export_DllMain@12
. When modifying the executable to importDllMain
, my own DllMain function runs, causing the program to fail to start (as intended, in this test case).When testing with a program that instead uses
LoadLibrary()
, my code will run in both cases, indicating that there's different behavior for a DLL being linked and loaded programmatically. I'm not an expert on how DLLs are loaded, but it seems like there's an entrypoint function that is run when the DLL is linked, and the entrypoint will only run DllMain when its symbol is specificallyDllMain
instead of the also valid_DllMain@12
.I tried this code:
(crate-type is set to
cdylib
)I expected to see this happen: When the DLL is linked, the program fails due to DllMain returning
false
Instead, this happened: The DLL links successfully, with DllMain seemingly returning
true
Meta
rustc --version --verbose
:The text was updated successfully, but these errors were encountered: