With the current approach, is relay exclude from effective even for `GetProcAddress` calls inside `DllMain`? My guess is that this is more of a side effect than an intentional behavior, and not something we necessarily need to preserve.
I guess. To be honest I have very little idea how developers (or users) use +relay or +snoop.
Since this mechanism can't be fully precise (`DllMain` might call functions from a different module) and we don't use such `GetProcAddress` calls inside Wine DLLs, where this feature is typically applied, I'm wondering if we could simplify it by treating `is_dynamic` as a `NULL` user here.
Like this?
```suggestion:-0+0 const WCHAR *user = !current_importer->is_dynamic ? current_importer->modref->ldr.BaseDllName.Buffer : NULL; ```
Perhaps we could even pass an argument like `user_modref`
You mean turning the `current_importer` global into a local parameter with such name?
Here's a graph for how `current_modref` value is being passed around:
```mermaid graph TB fixup_imports_ilonly["fixup_imports_ilonly<br><em style='color:yellow'>(directly sets current_modref)</em>"] fixup_imports["fixup_imports<br><em style='color:yellow'>(directly sets current_modref)</em>"] process_attach["process_attach<br><em style='color:yellow'>(directly sets current_modref)</em>"]
fixup_imports_ilonly --> load_dll fixup_imports --> import_dll process_attach --> MODULE_InitDLL MODULE_InitDLL -.-> DllMain
import_dll["import_dll<br><em style='color:lime'>(directly uses current_modref)</em>"] import_dll --> build_import_name["build_import_name<br><em style='color:lime'>(directly uses current_modref)</em>"] import_dll --> load_dll import_dll --> find_ordinal_export["find_ordinal_export<br><em style='color:lime'>(uses current_modref for relay)</em>"] import_dll --> find_named_export
find_ordinal_export --> find_forwarded_export["find_forwarded_export<br><em style='color:lime'>(directly uses current_modref)</em>"]
find_named_export --> find_ordinal_export
find_forwarded_export --> find_ordinal_export find_forwarded_export --> find_named_export find_forwarded_export --> build_import_name
style DllMain color:red; ```
The arrows indicate how the `current_modref` value flows from which caller to which callee. If we make it a explicit parameter, all the edges above will be turned into an argument.
This is a nontrivlal refactoring and I'm slightly uncomfortable with any possible regressions it might cause, especially around passing `current_modref` through user code (e.g., DllMain).
and exclude `LdrGetProcedureAddress` from the relay exclude from mechanism by passing `NULL`? I haven’t tried implementing this to confirm, but I’m curious if you’ve considered it.
`current_modref` is not just for +relay. It's also needed for builtin/native differentiation for handling DLL paths (`import_dll`), accurate dependency tracking between modules (`find_forwarded_export`), and building import names (`build_import_name`).
Overall, !364 has a nice graph that visualizes what this PR solves.