Remove printing of DacpModuleData::PEAssembly from DumpModule command

[elinor-fung]

dotnet/runtime#103821 changes the PEAssembly field to actually be the Module.

Per dotnet/runtime#103821 (comment), remove printing it to avoid confusion.

[jkotas]

Tests may need updating

[leculver]

SOS supports both Desktop Framework and .Net Core. Merging this change would make Desktop Framework debugging worse. (Also this code still needs to work on .Net 7 and 8 while they are still in support.)

Instead, you should test whether .PEAssembly is equal to .Address and conditionally print it to preserve debugging the other runtime.

[jkotas]

Merging this change would make Desktop Framework debugging worse.

IMHO, this change makes the .NET Framework debugging better and less confusing. The value that this line prints on .NET Framework is actually Module's PEFile, that may or may not be PEAssembly. And if somebody wants to look at PEFile, it is a simple field in the Module type. It is trivial to fetch it using regular windbg debugger commands.

I do not have strong opinions about what this should do on .NET Framework. I am fine with keeping the .NET Framework behavior intact with all its quirks.

you should test whether .PEAssembly is equal to .Address and conditionally print it to preserve debugging the other runtime.

I like the idea of deleting clutter from the output of these commands. We can also do the same for module.dwModuleID and module.dwModuleIndex and print them only when they are non-zero. These concepts do not exist anymore. The DAC returns constant 0 for these fields: https://github.com/dotnet/runtime/blob/8e92aef5387fe1d4b9159b4a3657416ac7d0a05a/src/coreclr/debug/daccess/request.cpp#L1738-L1739.

[leculver]

And if somebody wants to look at PEFile, it is a simple field in the Module type. It is trivial to fetch it using regular windbg debugger commands.

We don't ship private symbols for desktop framework. This is something SOS/dac produces without having them.

I'm also in favor of removing clutter from commands, like displaying dwModuleID/dwModuleIndex only when non-zero. I just don't want to remove potentially useful bits for Desktop Framework as an accidental biproduct of changes here when avoidable.

[jkotas]

We don't ship private symbols for desktop framework. This is something SOS/dac produces without having them.

Can you do anything useful with PEAssembly pointer if you do not have private symbols? I think PEAssembly pointer is completely useless without private symbols.

[leculver]

I don't know all of the use cases of SOS. I'd simply prefer not to remove functionality if we don't have to.

You can still implement all of the .Net Core related functionality here without affecting Desktop Framework debugging.

[leculver]

Stepping back a second, the principle I'm trying to articulate is this:

When possible, please don't regress or take back Desktop Framework debugging features, as some of us still have to regularly debug that product. (Of course, I also mean when it wouldn't be too much work. I am not trying to hold anyone back.) As long as this version of SOS continues to support Desktop Framework, I think that's a reasonable position to take.

In this particular case, you are still able to make the changes you want to the output...it only means adding an if statement to maintain the status quo for Desktop. Feel free to change the text of "PEAssembly" to something more correct, always happy to have improvments. :)

I think that's a pretty reasonable (and not onerous) request, regardless of how useful the functionality is. Much appreciated!

[jkotas]

When possible, please don't regress or take back Desktop Framework debugging feature

I agree.

Feel free to change the text of "PEAssembly" to something more correct, always happy to have improvements. :)

Well, I am saying that the improvement would be to delete it unless somebody can explain why it is useful. This information was not in DumpModule output in the .NET Framework golden days and nobody missed it enough to add it to the output.

It was added to DumpModule output recently as part of 3000+ lines change that added support for ELF dumps: #124 . I am not sure why Mike added it. I do not see any paper trail that explains why it is useful to have this information in the DumpModule output.

[mikem8361]

I don't remember why I added it of course. I'm completely ok with making these kind of SOS improvements.

[mikem8361]

The SOS tests are failing because they expect a PEAssembly in the output. Line 91 in src\SOS\SOS.UnitTests\Scripts\OtherCommands.script needs to be removed.

[elinor-fung]

@leculver - completely agree with the higher level principle around Framework debugging experience and appreciate you calling it out here. For this particular case, per #4751 (comment) and #4751 (comment), this was a relatively recent addition that was never part of the original Framework experience, so I kept this PR as unconditionally removing the output.