[mobile][diagnostics] Format native crash output using llvm-symbolizer markup

[lambdageek]

Use case:

I'm a C# android developer. I am capable of reproducing a native crash in my app and I can run adb log. In addition to the standard android crash dump summary, I would like the .NET runtime to print out its own view of a native backtrace using llvm-symbolizer markup so that I can use that output together with dotnet-symbol to view native stack traces that include line number information.

There's three tasks here:

1. Modify dump_native_stacktrace to use {{bt:...}} markup to print stack frame addresses.
2. Emit {{module:}} and {{mmap:...:load:...}} markup to print out the ELF BuildId of each module and the memory map info for each loaded that appears in the stack traces (probably dladdr and some kind of dlinfo will get this data)
3. Modify dump_native_stacktrace to use "unwind.h" and _Unwind_backtrace on Android to iterate over stack frames. (Android doesn't have backtrace that we use on other platforms)

[dotnet-policy-service]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

[lambdageek]

/cc @mdh1418

[lambdageek]

To get the build ids, I guess you need to do a dl_iterate_phdr and look through each dl_phdr_info's dl_phdr with p_type == PT_NOTE and then for BuildID note. there is some useful example at https://github.com/mattst88/build-id

[tommcdon]

Potential duplicate issues:

• Packaging & redistribution of mdoc.exe & mono-symbolicate in a .NET 6 world? #35852
• Support for stack trace source location reconstruction #46552

[tommcdon]

Possible workaround - dotnet/android#8832 (comment)

[lambdageek]

Potential duplicate issues:

• Packaging & redistribution of mdoc.exe & mono-symbolicate in a .NET 6 world? #35852
• Support for stack trace source location reconstruction #46552

These issues are about managed stack traces and adding line number info to android logs based on MVID of the managed stack frames. The current issue is about unmanaged stack traces.

Possible workaround - dotnet/android#8832 (comment)

That workaround is just about displaying the unmanaged stack traces (likely with missing symbol names) - currently the runtime just swallows its own attempts at printing those. After the workaround there is still the question of how to ensure that it's possible to get the symbol names for the native addresses that appear in the log. (ie: the current issue is about enhancing the workaround)