Hosting SOS under ClrMd for ELF dumps. #124
Conversation
Change SOS.NETCore to the "netstandard2.0" framework.
Add runtineOnly option to LoadNativeSymbols to use to get DAC/DBI module name. Use LoadNativeSymbols(true) to get the DAC/DBI modules when don't exist locally.
Cleanup GetCoreClrDirectory service function. No need to have separate GetModuleDirectory method. DacpGetModuleData.Request fails on some modules. Skip them in GetModuleFromAddress. Cleanup some spurious error messages in stack trace commands.
|
@jonsequitur if you have time, could you take a quick look how I used System.CommandLine in the "Add Microsoft.Diagnostic.Utilities containing console, command and help functions." commit. Thanks. |
|
A good deal of the usage of System.CommandLine here covers territory that either I'm working to make easier with my binding PR (dotnet/command-line-api#408) or that Kathleen is working to make easier with her app model work (currently no open PR). We should chat this week. |
|
When your and Kathleen's work is finished and in, I'll look at using at some point. We don't want to wait or depend on this future work (just for now). |
There was a problem hiding this comment.
A few odds and ends I noticed, but mostly looks fine.
One big open question, what is the plan for testing? I don't think we need to re-test the details of SOS commands that are tested elsewhere, but there are thousands of new lines of code showing up and no corresponding testing so far. That makes me nervous.
|
For testing, I plan to modify the SOS runner to run |
|
How would you feel about shifting some of the emphasis from scenario tests to unit tests, and putting those unit tests in this repo that will run as part of the CI? The old SOS tests were awkward because it was difficult to run anything without being hosted in a debugger, and then it was difficult to interact with SOS other than through the command-line interface. But now that we own all the layers and it is primarily C# libraries, I think we could align with standard conventions much more closely. |
|
I do like the idea of unit tests without having to deal with a debugger like lldb or cdb. That is one reason I tried to put the actual SOS hosting functionality in a separate assembly (same with the SOS.Installer). Writing a xunit test directly without having the input script, etc would make it easier to test even more of the SOS commands. Given all that plumbing the dotnet-dump analyze repl into the current SOS runner would exercise the infrastructure better (the interop layer, command processor and even the console provider a little). I don't think it would take that much time to change the SOS runner. If we have time to both, that would be even better. |
|
Actually now that I think about this more, testing the native SOS commands through the SOSHost directly in a xunit test would exercise most of the infrastructure and the native SOS command itself. Using the SOS runner probably wouldn't give us that much coverage of the command processor/repl code. |
|
@noahfalk Thanks for all the feedback. I really appreciate the effort it takes for these reviews. I filed some follow up issues. Do you think this PR is ready to merge? |
There was a problem hiding this comment.
Go for it.
One suggestion either in this PR or a near future one. If that assembly resolver is only supposed to deal with SOS.NetCore.dll, I would add comments to that effect and ideally add checks in the code to ensure that you don't inadvertently start affecting the resolutions of other assemblies.
Use the System.CommandLine CommandProcessor for the new commands. Add "sos", "exit", "help", native "modules" and "setthread" commands.
Add interactive dump "analyze" dump support to dotnet-dump project.
Use the System.CommandLine CommandProcessor for the new commands.
Add "sos", "exit", "help", native "modules" and "setthread" commands.
Hosting SOS under ClrMd for ELF dumps.
Add Microsoft.Diagnostic.Utilities containing console, command and help functions.
Strike.cpp/util.cpp clean and fixes.
Cleanup GetCoreClrDirectory service function. No need to have separate GetModuleDirectory method.
DacpGetModuleData.Request fails on some modules. Skip them in GetModuleFromAddress.
Cleanup some spurious error messages in stack trace commands.
Cleanup ILLDBServices2 interface before it gets shipped.
Add runtineOnly option to LoadNativeSymbols to use to get DAC/DBI module name.
Use LoadNativeSymbols(true) to get the DAC/DBI modules when don't exist locally.
Upgrade to clrmd 1.0.3.
Change SOS.NETCore to the "netstandard2.0" framework.