-
Notifications
You must be signed in to change notification settings - Fork 5.3k
superpmi.py script improvements #42668
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
superpmi.py script improvements #42668
Conversation
1. Simplify and regularize superpmi and mcs tool finding: they are both looked for first in Core_Root, then in the built product directory, then on the PATH. 2. Improve JIT-EE version determination: first, search for the GUID by parsing corinfo.h, if found. Otherwise, use "mcs -printJITEEVersion" as before. 3. Improve JIT dll finding: search first in Core_Root, then in the built product directory. 4. When downloading coredistools, create the Core_Root if it doesn't exist. With these changes, you can build the "clr.runtime" subset then immediately run a replay or asmdiffs, without first generating a Core_Root directory. The script will automatically create the Core_Root directory simply to put coredistools in it (and also use it as the "current directory" when running superpmi commands).
d78a9d5 to
25b13f6
Compare
|
cc @dotnet/jit-contrib |
| 2. Find the mcs tool and run "mcs -printJITEEVersion". | ||
| 3. Otherwise, just use "unknown-jit-ee-version", which will probably cause downstream failures. | ||
| NOTE: When using mcs, we need to run the tool. So we need a version that will run. If a user specifies |
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.
We discussed lot of things today, so it is easy for me to forget. But remind me, even we will figure out guid in superpmi.py script itself, but in #42053 , I will still need coreclr x64 so I can run mcs.exe (eventually via superpmi.py) to merge/dedup .mcs files. Yes?
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 will still need coreclr x64 so I can run mcs.exe (eventually via superpmi.py) to merge/dedup .mcs files. Yes?
Yes.
| corinfo_h_jit_ee_version = match_obj.group(1) | ||
| print("Using JIT/EE Version from corinfo.h: {}".format(corinfo_h_jit_ee_version)) | ||
| return corinfo_h_jit_ee_version | ||
| print("Warning: couldn't find JITEEVersionIdentifier in {}; is the file corrupt?".format(corinfo_h_path)) |
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.
nit: put the "Warning: ..." under if verbose?
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.
Well, it's a pretty bad situation, so it probably warrants always being displayed.
I'm planning to revamp the whole output situation, creating log files, verbosity levels, etc.
kunalspathak
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 with a question.
src/coreclr/scripts/superpmi.py
Outdated
| # Make a more intelligent decision about the arch and build type | ||
| # based on the path of the jit passed | ||
| if standard_location and not coreclr_args.build_type in coreclr_args.jit_path: | ||
| if jit_in_product_location and not coreclr_args.build_type in coreclr_args.jit_path: |
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.
a nit: one operator versus two
| if jit_in_product_location and not coreclr_args.build_type in coreclr_args.jit_path: | |
| if jit_in_product_location and coreclr_args.build_type not in coreclr_args.jit_path: |
src/coreclr/scripts/superpmi.py
Outdated
| # Make a more intelligent decision about the arch and build type | ||
| # based on the path of the jit passed | ||
| if standard_location and not coreclr_args.build_type in coreclr_args.base_jit_path: | ||
| if jit_in_product_location and not coreclr_args.build_type in coreclr_args.base_jit_path: |
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.
| if jit_in_product_location and not coreclr_args.build_type in coreclr_args.base_jit_path: | |
| if jit_in_product_location and coreclr_args.build_type not in coreclr_args.base_jit_path: |
src/coreclr/scripts/superpmi.py
Outdated
| "Invalid build_type") | ||
|
|
||
| if standard_location and not coreclr_args.arch in coreclr_args.base_jit_path: | ||
| if jit_in_product_location and not coreclr_args.arch in coreclr_args.base_jit_path: |
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.
| if jit_in_product_location and not coreclr_args.arch in coreclr_args.base_jit_path: | |
| if jit_in_product_location and coreclr_args.arch not in coreclr_args.base_jit_path: |
for first in Core_Root, then in the built product directory, then on the PATH.
corinfo.h, if found. Otherwise, use "mcs -printJITEEVersion" as before.
product directory.
With these changes, you can build the "clr.runtime" subset then immediately run
a replay or asmdiffs, without first generating a Core_Root directory. The script
will automatically create the Core_Root directory simply to put coredistools in
it (and also use it as the "current directory" when running superpmi commands).