Add LoongArch 64-bit support

[lrzlin]

Add LoongArch 64-bit support for netcoredbg, which is a new RISC arch a bit like MIPS or RISC-V, for more informations about LoongArch, please refer Areweloongyet.

dotnet runtime & SDK already have a quite finite LoongArch 64 port, however as a community port, there are no official SDK released, so I use the community one for building & testing, after compiling libdbgshim.so and modify TargetFramework from netcoreapp3.1 to net9.0, it can pass most of tests in test-suite.

It's worth noticing that due to LoongArch's ptrace implement and __debug_trap() is slightly different with other architectures like x64/arm64, like SIGTRAP and SIGILL's si_code, so there are some macros for interop breakpoints could work properly.

Here are the test results

CLITestBreakpoint ... passed
CLITestInteropBreakpoint ... passed
MIExampleTest ... passed
MITestBreakpoint ... passed
MITestExpression ... passed
MITestVariables ... failed res=1
MITestStepping ... passed
MITestEvaluate ... passed
MITestException ... passed
MITestEnv ... passed
MITestGDB ... passed
MITestExecAbort ... passed
MITestExecInt ... passed
MITestHandshake ... passed
MITestTarget ... passed
MITestExceptionBreakpoint ... failed res=1
MITestExtensionMethods ... passed
MITestExitCode ... passed
MITestEvalNotEnglish ... passed
MITest中文目录 ... passed
MITestSrcBreakpointResolve ... passed
MITestEnum ... passed
MITestAsyncStepping ... passed
MITestBreak ... passed
MITestBreakpointToModule ... passed
MITestNoJMCNoFilterStepping ... passed
MITestNoJMCBreakpoint ... passed
MITestNoJMCAsyncStepping ... passed
MITestNoJMCExceptionBreakpoint ... failed res=1
MITestSizeof ... passed
MITestAsyncLambdaEvaluate ... passed
MITestGeneric ... passed
MITestEvalArraysIndexers ... passed
MITestBreakpointWithoutStop ... passed
MITestBreakpointUpdate ... passed
MITestUnhandledException ... passed
VSCodeExampleTest ... passed
VSCodeTestBreakpoint ... passed
VSCodeTestFuncBreak ... passed
VSCodeTestAttach ... passed
VSCodeTestPause ... passed
VSCodeTestDisconnect ... passed
VSCodeTestThreads ... passed
VSCodeTestVariables ... failed res=1
VSCodeTestEvaluate ... passed
VSCodeTestStepping ... passed
VSCodeTestEnv ... passed
VSCodeTestExitCode ... passed
VSCodeTestEvalNotEnglish ... passed
VSCodeTest中文目录 ... passed
VSCodeTestSrcBreakpointResolve ... passed
VSCodeTestEnum ... passed
VSCodeTestAsyncStepping ... passed
VSCodeTestBreak ... passed
VSCodeTestNoJMCNoFilterStepping ... passed
VSCodeTestNoJMCBreakpoint ... passed
VSCodeTestNoJMCAsyncStepping ... passed
VSCodeTestExceptionBreakpoint ... passed
VSCodeTestNoJMCExceptionBreakpoint ... passed
VSCodeTestSizeof ... passed
VSCodeTestAsyncLambdaEvaluate ... passed
VSCodeTestGeneric ... passed
VSCodeTestEvalArraysIndexers ... passed
VSCodeTestExtensionMethods ... passed
VSCodeTestBreakpointWithoutStop ... passed
VSCodeTestUnhandledException ... passed

Total tests: 66. Passed: 62. Failed: 4.

The failed tests seems to be architecture independent, they're failed too on x64-linux's net9.0 target. It's highly possible that dotnet version differences make them failed.

Related: loongson-community/discussions#84

[viewizard]

Thanks for your effort!

MITestVariables and VSCodeTestVariables should be fixed for 9.0, since runtime still have issue:
https://github.com/Samsung/netcoredbg/blob/master/test-suite/MITestVariables/Program.cs#L461-L464
https://github.com/Samsung/netcoredbg/blob/master/test-suite/VSCodeTestVariables/Program.cs#L557-L560

With this test fixes, all tests passed for me on x64-linux's net9.0 target (.NET SDK 9.0.301) and current netcoredbg upstream.

[xen0n]

Looks good overall in terms of LoongArch details, thanks!

Apart from this, there are some changed lines with apparently no change -- I suppose they are line ending changes due to mixed CRLF and LF usage in the original files respectively, and would be better to have them in a separate clean-up commit so the main commit can be focused. What do you think?

[lrzlin]

Thanks for your effort!

MITestVariables and VSCodeTestVariables should be fixed for 9.0, since runtime still have issue: https://github.com/Samsung/netcoredbg/blob/master/test-suite/MITestVariables/Program.cs#L461-L464 https://github.com/Samsung/netcoredbg/blob/master/test-suite/VSCodeTestVariables/Program.cs#L557-L560

With this test fixes, all tests passed for me on x64-linux's net9.0 target (.NET SDK 9.0.301) and current netcoredbg upstream.

Thanks for your advice! After adding System.Environemnt.Version.Major == 9, MITestVariables and VSCodeTestVariables could passed on LoongArch platform, however MITestExceptionBreakpoint and MITestNoJMCExceptionBreakpoint still failed, it seems to be a dotnet runtime bug, here are the MITestExceptionBreakpoint's fail log:

< (gdb)
< *stopped,reason="exception-received",exception-name="System.Exception",exception="An exception of type 'System.Exception' occurred in MITestExceptionBreakpoint.dll but was not handled in user code",exception-stage="user-unhandled",exception-category="clr",thread-id="5338",stopped-threads="all",frame={clr-addr={module-id="{9221a76b-8938-4bc2-9cdf-a8a8aa7e532e}",method-token="0x060047ba",method-version="1",il-offset="0",native-offset="72"},func="System.Runtime.StackFrameIterator.Init()",addr="0x0000000000000000",active-statement-flags="MethodUpToDate"}
< (gdb)
Script running is failed. Got exception:
System.Collections.Generic.KeyNotFoundException: The given key 'file' was not present in the dictionary.
   at NetcoreDbgTestCore.ControlScript.ExecuteCheckPoints(ControlInfo ControlInfo, DebuggerClient DebuggerClient) in /home/lrzlin/netcoredbg/test-suite/NetcoreDbgTest/ControlScript.cs:line 134
   at NetcoreDbgTestCore.ControlPart.Run(ControlScript script, DebuggerClient debugger, Environment env) in /home/lrzlin/netcoredbg/test-suite/NetcoreDbgTest/ControlPart.cs:line 14
   at TestRunner.Program.Main(String[] args) in /home/lrzlin/netcoredbg/test-suite/TestRunner/TestRunner.cs:line 117

MITestExceptionBreakpoint ... failed res=1

Both tests failed on System.Runtime.StackFrameIterator of some kind, maybe we'll test whether these two tests works well on lastest dotnet runtime to see whether it's fixed or not.

[lrzlin]

Apart from this, there are some changed lines with apparently no change -- I suppose they are line ending changes due to mixed CRLF and LF usage in the original files respectively, and would be better to have them in a separate clean-up commit so the main commit can be focused. What do you think?

Seems to be my editor will remove trailing spaces automatically when save files, I've reverted them in README.md, as rest of them isn't too much, keeping them should be well IMO.

[driver1998]

Looks like sdb_run_tests.sh is also for Tizen only, from its help:

print_help()
{
    echo "Usage: sdb_run_tests.sh [OPTION]... [TEST NAME]..."
    echo "Run functional tests on Tizen target device."
    echo ""
    echo "  -s, --sdb         sdb binary, \"sdb\" by default"
    echo "  -p, --port        local tcp port, \"4712\" by default"
    echo "  -d, --dotnet      dotnet binary, \"dotnet\" by default"
    echo "      --repeat      repeat tests, \"1\" by default"
    echo "  -g, --gbsroot     path to GBS root folder, \"\$HOME/GBS-ROOT\" by default"
    echo "  -p, --tools_path  path to tools dir on target,"
    echo "                    \"/tmp\" by default"
    echo "  -r, --rpm         path to netcordbg rmp file"
    echo "  -x, --xml_path    path to test-results xml xunit format file,"
    echo "                    \"/home/owner/share/tmp/\" by default"
    echo "  -c, --coverage    create code coverage report, do not create by default"
    echo "      --help        display this help and exit"
}

[viewizard]

I will move this PR into our internal dev repo for internal CI testing. This changes will be in upstream with next public repo update.

[gbalykov]

Thanks for your contribution, this is part of latest release