Support loading standalone GC from an absolute path using a new config named `DOTNET_GCPath`

[cshung]

Right now, we only support loading the standalone GC through the DOTNET_GCName config. By default, it will load the standalone GC assuming the config specified the name of the file, and then it will load it from the directory hosting coreclr.dll.

That location is often inaccessible (e.g. it is under C:\Program Files for windows) for the person who need to patch it.

In this issue, I propose the following:

We supporting loading from these locations if DOTNET_GCName is specified:

1.) The user's app-base (i.e. where they put their managed DLLs), this is the most intuitive place to load the file from. Most customers should have no problem updating that location because that is where they write their app to.

2.) The shared SDK dir (this is where we ship our binaries to), that make it easy for customer to try segments to isolate regions bug (or vice versa on OSX)

Or if someone specified a DOTNET_GCPath, a new config, then just treat that as an absolute path and load it from wherever they specified. Put some warnings on the doc to remind users to make sure the location is secured (*).

(*) Right now, we could specify a relative path in DOTNET_GCName to load from whatever location, they change doesn't make anything less secure.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

[jkotas]

The user's app-base (i.e. where they put their managed DLLs), this is the most intuitive place to load the file from.

Nit: The place where the apps loads its native .dll/.so/.dylib from would be more intuitive.

The shared SDK dir

I do not think we want to be encouraging people to manually copy random .dlls into the shared runtime installation. It has the same problem with being inaccessible). Also, you would need to detect the layout of the runtime installation and only do this for shared runtimes that is tricky.

[markples]

There are two separate proposals here - changes to the search path and the addition of a second (DOTNET_GCPath) config. For the second, I'd like to propose just allowing DOTNET_GCName to be an absolute path. Windows PathCchCombine and Python os.path.join already have the behavior where combining an absolute path ignores the previous path(s), so this would make DOTNET_GCName follow that pattern (DOTNET_GCName is being combined with the elements of the search path).

If we add a new DOTNET_GCPath, do we restrict DOTNET_GCName to be simple names? (error: pass this as GCPath instead?) Or does DOTNET_GCName continue to support some (relative) paths but not all?

I also wonder if this and JIT loading should be consistent.

[cshung]

I am getting back to work on this issue, starting with studying the JIT loading behavior.

They have two config variables:

DOTNET_JitPath can be used to specify a full path to the JIT module, or
DOTNET_JitName can be used to specify a name of the JIT module.

DOTNET_JitName is subjected to ValidateJitName, which is intentional to ban relative path.
DOTNET_JitName is appended to the folder containing the coreclr module.

DOTNET_JitPath is debug only.

Compared with our current state, we have

DOTNET_GCPath does not exist, and
DOTNET_GCName can be used to specify a name of the GC module.

DOTNET_GCName is not subjected to any verification.
DOTNET_GCName is appended to the folder containing the coreclr module.