-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Set AssemblyName.ProcessorArchitecture for compatibility. #80581
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
Conversation
|
Tagging subscribers to this area: @dotnet/area-system-reflection-metadata Issue DetailsFixes: #77697 ProcessorArchitecture was unintentionally omitted when
|
...ries/System.Reflection.Metadata/src/System/Reflection/Metadata/MetadataReader.netstandard.cs
Outdated
Show resolved
Hide resolved
|
|
||
| private static ProcessorArchitecture CalculateProcArchIndex(PortableExecutableKinds pek, ImageFileMachine ifm, AssemblyFlags flags) | ||
| { | ||
| if (((uint)flags & 0xF0) == 0x70) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any idea what this is trying to check for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is one place that calls 0xF0 is ProcArchMask
runtime/src/libraries/System.Private.CoreLib/src/System/Reflection/AssemblyNameFlags.cs
Line 13 in 57bfe47
| // ProcArchMask = 0x00F0, // Bits describing the processor architecture |
I suspect 0x70 means None, but that is just a guess.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Old NDP sources have this:
// 0x70 specifies "reference assembly", a new concept in v4.0. For these, CLR wants to return None as arch so they
// can be always loaded, regardless of process type. There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've checked a few reference assemblies. The COFF header specifies machine as I386 and CorFlags are ILOnly, so this does look like needs to be handled in a special way.
Otherwise the suggested simplified way will return MSIL while expected to return None
|
I think that this logic is very convoluted. I would simplify into something that one can reason about. For example: It will behave differently from the current convoluted logic for invalid images (ie images that would not execute anyway - like x86 image with PE32+ header, etc.). I think that it is ok. |
|
We can potentially apply the same simplification in the CoreCLR copy as well. |
Yes. I think we might be ok with duplication, since this is legacy and will not change often, if at all, and only needed in two places. But if implementations do not match, it could be confusing why the differences. |
jkotas
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
|
Thanks!! |
|
/backport to release/7.0 |
|
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3998851487 |
Fixes: #77697
Computing and setting
ProcessorArchitecturewas unintentionally omitted whenGetAssemblyName(path)was switched to a managed implementation.This will need to be backported to 7.0