-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Some more cleanups in Assembly/Binder/Loader area #59590
Conversation
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov Issue DetailsIn-progress. Running tests. One of the goals is to combine Later we should look at how much sharing is between
|
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.
Looked through the headers so far.
I'm a pretty slow reviewer over here 😬
src/coreclr/vm/peassembly.cpp
Outdated
// TODO: we used to return "m_pMDImport_UseAccessor" here, - a field that was never initialized to anything. | ||
// we should verify whether this codepath is actually reachable. | ||
// return (TADDR)m_pMDImport_UseAccessor; |
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.
@dotnet/dotnet-diag?
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.
This code is weird, but should be left as it was.
We rename PEFile::m_pMDImport to m_pMDImport_UseAccessor when compiling for the DAC, because we want it to be a compile error if anybody tries to use m_pMDImport in the DAC, since m_pMDImport is the TADDR (debuggee side address) and not a PTR_* that knows how to magically read the value from the debuggee.
However, this one method we actually want to read the TADDR value , do we use m_pMDImport_UseAccessor directly in the DAC code. The code in DacDbiInterfaceImpl::GetPEFileMDInternalRW calls GetMDInternalRWAddress, which will read the right value since m_pMDImport_UseAccessor has the same type and offset as m_pMDImport
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.
Thanks @davmason!! I think I got it. I also think this deserves a better comment. It is fairly hard to figure where and how this field is used by just searching around.
I will try adding your comment there as well in some form - at least it would hint that there is more going on than a textual search might reveal.
Co-authored-by: Elinor Fung <[email protected]>
@elinor-fung @davmason - I think I have addressed all the comments. Please take a look that all makes sense and I did not miss something. |
// be the parent assembly for dynamic or memory assemblies | ||
const SString& GetEffectivePath(); | ||
|
||
// Codebase is the fusion codebase or path for the assembly. It is in URL format. |
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.
Another reference to "fusion" which should be removed.
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.
Quick search finds 48 references to "fusion" in the comments. It is not always clear how to re-word them, and the old context may still be useful while refactoring.
I think it may be worth to revisit "fusion" comments a bit later. Fortunately it is such an easy thing to find.
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.
The diagnostics side stuff looks good to me, I didn't take a look at the broader code changes though
@@ -4299,7 +4286,7 @@ HRESULT ProfToEEInterfaceImpl::GetILFunctionBody(ModuleID moduleId, | |||
// Yay! | |||
MODE_ANY; | |||
|
|||
// PEFile::CheckLoaded & Module::GetDynamicIL both take a lock | |||
// PEAssembly::HasLoadedPEImage & Module::GetDynamicIL both take a lock |
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.
Is this still true for PEAssembly::HasLoadedPEImage
?
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.
Not true for PEAssembly::HasLoadedPEImage
, but still true for Module::GetDynamicIL
src/coreclr/vm/peassembly.cpp
Outdated
{ | ||
WRAPPER_NO_CONTRACT; | ||
SUPPORTS_DAC; | ||
|
||
// sizeof(PEFile) == 0xb8 | ||
// sizeof(PEAssembly) == 0xb8 |
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.
Is this comment about the size still true?
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.
Most likely not and I do not know what it means. I do not think we have dependency on the size of the instance and I am not sure the size was correct before - was it for x86 or x64, etc?
There is no PEFile
anyways. I will remove the comment.
Co-authored-by: Elinor Fung <[email protected]>
@elinor-fung - anything else that could be addressed on this PR? |
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.
Sorry - completely missed coming back to this. Looks good to me.
Thanks!! They were good suggestions. |
More tidy-up and removal of no longer necessary code.
AppDomain::Create
As discussed in the previous PR.
PEFile
intoPEAssembly
. We only havePEAssembly
now.All the PE files we deal with are assemblies and
PEFile
is unnecessary abstraction that was created to support modules, resource-only files,IStream
things provided by SQL host, etc... None of that exists any more.PEAssembly
change.Unlike
PEFile
,PEAssembly
is always an assembly, never a native Resource PE, always has metadata, hasMDImport
right after construction, itsPEImage
is opened at construction and also has metadata, and so on...Many checks and conditions could be simplified.
AppDomain
no longer has a scenario when a hosted assembly is updated after publishing, so the code supporting such scenario can be removed.PEImage
- moved instance filed declarations together, sorted related public/private members, removed unused/redundant stuff.I.E.
GetLayout
is always called withLAYOUT_CREATEIFNEEDED
, so the flag is unnecessary, and similar changes. Overall functionality is the same as before.