sosplugin is not working on ARM

[wfurt]

I tested this in my RP3 as well as Ubuntu on Qemu. I'm not even able to get list of commands.

pi@raspberrypi:~/aa $ lldb-4.0 ../dotnet-2.1.302/dotnet -- bin/Debug/netcoreapp2.1/aa.dll
(lldb) target create "../dotnet-2.1.302/dotnet"
Current executable set to '../dotnet-2.1.302/dotnet' (arm).
(lldb) settings set -- target.run-args  "bin/Debug/netcoreapp2.1/aa.dll"
(lldb) r
Process 16576 launched: '../dotnet-2.1.302/dotnet' (arm)
Hello World!
Going to sleep!
Process 16576 stopped
* thread dotnet/coreclr#1, name = 'dotnet', stop reason = signal SIGSTOP
    frame #0: 0x76f88ce8
->  0x76f88ce8: svc    #0x0
    0x76f88cec: cmn    r0, dotnet/coreclr#4096
    0x76f88cf0: mov    r5, r0
    0x76f88cf4: ldrls  r4, [sp]
(lldb) plugin load ../dotnet-2.1.302/shared/Microsoft.NETCore.App/2.1.2/libsosplugin.so
(lldb) sos
(lldb) sos help
Stack dump:
0.	HandleCommand(command = "sos help")
Segmentation fault

I did same steps on x64 and lldb-4.0
(lldb) sos

SOS is a debugger extension DLL designed to aid in the debugging of managed
programs. Functions are listed by category, then roughly in order of
...
...

(lldb) sos help
SOS command 'help' not found /home/furt/dotnet-2.1/shared/Microsoft.NETCore.App/2.1.0/libsos.so: undefined symbol: help

[abbotware]

FYI - Same problem I have on aarch64 using lldb-3.8(armhf) and lldb-3.9(arm64) - i installed both 32 and 64 bit on the same machine just to see if it was a 32bit vs 64bit library loading issue

[RussKeldorph]

@echesakovMSFT

[wfurt]

just a note that it seems to work when I build it my self. (#18827) I'm suspicious this may be build problem .

[echesakov]

I also ended up building lldb5.0.2+sosplugin for arm myself. In my case "official" lldb couldn't even run target process with the following message error: process launch failed: Lost debug server connection.

[abbotware]

It sounds like there are issues, but is there a process to get to a known working state so I can at least get some deadlock / hang analysis done on Linux Arm32?

From what I am reading, if I do the following:

Build LLDB 5.0.2?
Build SOS Plugin? (which source version)
Build .Net Core?

on my 'target' hardware, should I have a working way to do dump analysis? (or attach to a hung process)

[wfurt]

I simply build coreclr with what ever version of lldb you plan to use (5.0 in my case)
You do not need to build lldb it self but you need lldb-dev (or equivalent package)

Also note, that on arm32 you can use Visual Studio for remote debug.

[mikem8361]

Issue moved to dotnet/diagnostics dotnet/coreclr#41 via ZenHub