Support for more Core and ELF formats

[am11]

.NET runtime is being made available on more flavors of Unix, that happen to have different ELF formats. Diagnosing issues by means of coredumps generated in those environments is currently not feasible.

One example, which I ran into, is Linuxulator on FreeBSD, where dotnet(1) Linux binary with Roslyn's csc.dll assembly aborted and generated a coredump in FreeBSD's core(5) format. Running dotnet dump analyze resulted in:

[vagrant@freebsd ~/myapp]$ dotnet dump analyze myapp.core 
Loading core dump: myapp.core ...
Unhandled exception: System.BadImageFormatException: No auxv entries in coredump
   at Microsoft.Diagnostics.Runtime.Linux.ElfCoreFile.LoadAuxvTable()
   at Microsoft.Diagnostics.Runtime.Linux.ElfCoreFile.GetAuxvValue(ElfAuxvType type)
   at Microsoft.Diagnostics.Runtime.CoredumpReader.EnumerateModules()
   at Microsoft.Diagnostics.Runtime.Linux.LinuxDefaultSymbolLocator..ctor(IDataReader reader)
   at Microsoft.Diagnostics.Runtime.DataTarget..ctor(CustomDataTarget customTarget)
   at Microsoft.Diagnostics.Runtime.DataTarget.LoadDump(String displayName, Stream stream, CacheOptions cacheOptions, Boolean leaveOpen)
   at Microsoft.Diagnostics.Runtime.DataTarget.LoadDump(String filePath, CacheOptions cacheOptions)
   at Microsoft.Diagnostics.Tools.Dump.Analyzer.Analyze(FileInfo dump_path, String[] command) in /_/src/Tools/dotnet-dump/Analyzer.cs:line 57
   at System.CommandLine.Invocation.CommandHandler.GetResultCodeAsync(Object value, InvocationContext context)
   at System.CommandLine.Invocation.ModelBindingCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseParseErrorReporting>b__21_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass25_0.<<UseVersionOption>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass23_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__22_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseParseDirective>b__20_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseDebugDirective>b__11_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__10_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass14_0.<<UseExceptionHandler>b__0>d.MoveNext()

It would be helpful if the Diagnostics runtime recognize varied ELF formats, and provide the consumer (such as dotnet-dump) with common info sections + OS specific info sections (such as, NT_AUXV which the aforementioned exception is about).

Currently, the following elf(5) formats are possible with .NET runtime which Diagnostics runtime does not support:

• FreeBSD: https://www.freebsd.org/cgi/man.cgi?query=elf&apropos=0&sektion=5&manpath=FreeBSD+13.0-current&arch=default&format=html
• illumos: https://illumos.org/man/3ELF/elf
• NetBSD: https://man.netbsd.org/elf.5

[leculver]

@mikem8361 As an FYI. (Not asking you to fix this, just a heads up that dotnet-dump analyze isn't working properly on these platforms.)

[mikem8361]

Yes, I did see this issue at some point.