-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[LoongArch64] coreclr/debug and part of inc directory. #62886
Conversation
update from runtime.
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
Co-authored-by: Loongson's .NET-teams
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What ohter files are dependent on the windows for this PR ?
…ONGARCH64 on windows.
…URE_LOONGARCH64 on windows.
@@ -346,6 +346,12 @@ JitInstance::Result JitInstance::CompileMethod(MethodContext* MethodToCompile, i | |||
matchesTargetArch = (targetArch == SPMI_TARGET_ARCHITECTURE_ARM64); | |||
break; | |||
|
|||
#ifdef TARGET_UNIX |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of adding this ifdef, it would be better to define IMAGE_FILE_MACHINE_LOONGARCH64
on Windows.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry, where is the defination on windows?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant that you can define IMAGE_FILE_MACHINE_LOONGARCH64
in a place that shared between Windows and non-Windows so that these ifdefs are not necessary.
src/coreclr/inc/clrnt.h may be a good place to add IMAGE_FILE_MACHINE_LOONGARCH64
definition that is shared between Windows and non-Windows.
Try adding this:
#ifndef IMAGE_FILE_MACHINE_LOONGARCH64
#define IMAGE_FILE_MACHINE_LOONGARCH64 0x6264
#endif
at https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/clrnt.h#L1032
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#ifndef IMAGE_FILE_MACHINE_LOONGARCH64
#define IMAGE_FILE_MACHINE_LOONGARCH64 0x6264
#endif
Thanks~
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the compiling error is still exist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant that you can define
IMAGE_FILE_MACHINE_LOONGARCH64
in a place that shared between Windows and non-Windows so that these ifdefs are not necessary.src/coreclr/inc/clrnt.h may be a good place to add
IMAGE_FILE_MACHINE_LOONGARCH64
definition that is shared between Windows and non-Windows.Try adding this:
#ifndef IMAGE_FILE_MACHINE_LOONGARCH64 #define IMAGE_FILE_MACHINE_LOONGARCH64 0x6264 #endif
at https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/clrnt.h#L1032
It seems that it doesn't work.
src/coreclr/inc/cor.h
Outdated
@@ -2233,7 +2233,11 @@ inline ULONG CorSigCompressPointer( // return number of bytes of that compressed | |||
void * pvPointer, // [IN] given uncompressed data | |||
void * pData) // [OUT] buffer where iLen will be compressed and stored. | |||
{ | |||
#ifdef TARGET_LOONGARCH64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes like this should not be under. This change should be done for all architectures.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you are right.
Especially for CPU processors supporting unaligned memory accessing.
I will update it later with breaking up this PR into serval PRs.
src/coreclr/inc/corcompile.h
Outdated
// jirl $r0,$r21,0 ; Jump to the target | ||
DWORD m_rgCode[3]; | ||
|
||
DWORD m_padding; //aligning stack to 16 bytes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This structure has nothing to do with stack. Is the comment wrong?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This structure has nothing to do with stack. Is the comment wrong?
Yes.
I should add a macro at here, prestup.cpp-Line:2363 #elif defined(TARGET_ARM) || defined(TARGET_ARM64) || defined(TARGET_LOONGARCH64)
But I also have a question.
Previous within the .NET6-runtime, the initialing code is in the file src/coreclr/zap/zapimport.cpp:489
.
But now the zapimport.cpp had been deleted.
Not only the LoongArch64, the others architecturs also do nothing for initialing the m_rgCode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, CORCOMPILE_EXTERNAL_METHOD_THUNK
is no longer used. It would be best to delete it instead of trying to fix it up for LoongArch64.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I will delete it for LoongArch64.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes,
CORCOMPILE_EXTERNAL_METHOD_THUNK
is no longer used. It would be best to delete it instead of trying to fix it up for LoongArch64.
Maybe I have to keep a define for LoongArch64 as the same with other architecture rather than compiling error for undefined value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am deleting it in #65869
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am deleting it in #65869
OK, I will update it after you merge that.
Thanks
Liking the compiling error #62843 (comment)
This PR's error on windows is also for undefined |
I think you may need to add |
OK, Thanks. |
I had added I guess windows and linux included different files for different macro-define, for example, the file I will submit a temp patch for testing. |
Adding this to palclr.h instead is fine - assuming that it is going to fix all build breaks on Windows. |
Hi, @jkotas Now the CI's errors are about the libunwind which is only on cross-arm64-windows, liking
How should I resolv this error ? |
This is CI infrastructure issue affecting all PRs: #65818. Do not worry about it. |
* Part6-2: -add the coreclr-vm directory for LoongArch64. (#59561) Co-authored-by: Loongson's .NET-teams * [LoongArch64] revert the syncblk.cpp. * [LoongArch64] delete some unused codes. * [LoongArch64] add vm/CMakeLists.txt from #62889. * [LoongArch64] add related files from #62886 and #62893. * [LoongArch64] moved vm/jitinterface.cpp from #62893. moved inc/corinfo.h from #6288. * [LoongArch64] run the file `src/coreclr/tools/Common/JitInterface/ThunkGenerator/gen.sh` and merge the patch from #62893. * [LoongArch64] revert vm/ceeload.h. amend the `ToolBox/superpmi/superpmi-shared/agnostic.h` * [LoongArch64] add empty interfaces within `CorInfoImpl.cs`. * [LoongArch64] Fix the compiling error on Windows. * [LoongArch64] Fix the compiling error for memory unaligned m_currentByteStackIndex. * [LoongArch64] Delete the !TARGET_LOONGARCH64 for m_currentByteStackIndex. * [LoongArch64] move ToolBox from #62886. * [LoongArch64] amend the args when needs unsigned extending within CallTargetWorker. * [LoongArch64] add bool type for args' unsigned extention. * [LoongArch64] adding char type for args' unsigned extention. Also rename `TARGET_LOONGARCH64` to `UNIX_LOONGARCH64_ABI` within ABI. * [LoongArch64] amend renaming `TARGET_LOONGARCH64` to `UNIX_LOONGARCH64_ABI` within ABI. * [LoongArch64] remove the JIT/EE interface to #62893. * [LoongArch64] revert the rename `TARGET_LOONGARCH64` to `UNIX_LOONGARCH64_ABI`. Also add unsigned extend for CHAR type. * [LoongArch64] refactor the `ArgDestination and ArgLocDesc`. * [LoongArch64] rename the `m_flag` and `getFieldTypeByHnd`. * [LoongArch64] add `NATIVE_SYMBOL_READER_DLL` for compiling error. * [LoongArch64] update the version of the `LICENSE description`. * [LoongArch64] keep same with the comment in `jit/targetloongarch64.h` * [LoongArch64] amend the code for reviewing. * [LoongArch64] refactor LoongArch64-ABI within `vm`, and also amend some code for review. * [LoongArch64] delete unused codes. * [LoongArch64] merge main for #65869. * [LoongArch64] amend the format for reviewing. * [LoongArch64] delete some unused code for reviewing. * [LoongArch64] amend code for CR feedback @jkotas @janvorli * [LoongArch64] add class type for LoongArch64-ABI. * [LoongArch64] Amend the LoongArch64's ABI after merged `MethodTable::GetLoongArch64PassStructInRegisterFlags()` and `CEEInfo::getLoongArch64PassStructInRegisterFlags()` * [LoongArch64] Fix the assert error when running hello-world within debug-mode after refacting. Co-authored-by: qiaopengcheng <qiaopengcheng-hf@loongson.cn>
@mikem8361 @hoyosjs |
Hi, @tommcdon |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like you have a lot to implement. Am I looking at this too soon?
@shushanhf I'm a bit curious. Are you working on LoognArch .NET runtime project alone? I've been tracking the PR for a few months. Looks you are the only person committing code. I do suggest you involve a team instead of yourself because this is a huge task. |
@mikem8361 Does you think more needs to be implemented before this change can be merged? I.e., is this wrong as-is, or just incomplete from a "full implementation" perspective? I presume that there will be additional work to make LoongArch64 a complete implementation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like everything is implemented now. Thanks.
[LoongArch64] coreclr-inc,gc, ToolBox directory.