-
Notifications
You must be signed in to change notification settings - Fork 13.4k
"fatal error: unknown codeview register H1" when using @llvm.dbg.value
on a half float parameter on aarch64-windows
#56484
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
Comments
@llvm/issue-subscribers-bug |
@llvm/issue-subscribers-backend-aarch64 |
@llvm/issue-subscribers-debuginfo |
LLVM does not properly handle debug info for f16 on the aarch64-windows target, causing "fatal error: unknown codeview register H1". The previous workaround checked only for f16 but was still vulnerable if a type was a byval struct or tuple which had an f16 field in it. Now I have filed an upstream issue (see llvm/llvm-project#56484) and broadened the workaround to always skip debug values for this target.
LLVM does not properly handle debug info for f16 on the aarch64-windows target, causing "fatal error: unknown codeview register H1". The previous workaround checked only for f16 but was still vulnerable if a type was a byval struct or tuple which had an f16 field in it. Now I have filed an upstream issue (see llvm/llvm-project#56484) and broadened the workaround to always skip debug values for this target.
Still present on Picking H1 makes sense because half float is 16 bit. Then we're trying to get the codeview register number for that. Except codeview only has the 32 bit (S) and and 64 bit (D) registers. ( It's the same over in Microsoft's repo https://github.com/microsoft/microsoft-pdb/blob/master/include/cvconst.h#L1603. Though there's always a chance that isn't up to date I suppose. I looked for half float support in msvc but I don't think it has it beyond https://docs.microsoft.com/en-us/windows/win32/dxmath/half-data-type but even if you use that I don't know that it would put it in a float register. None of the type names listed in https://clang.llvm.org/docs/LanguageExtensions.html#half-precision-floating-point work either. But regardless it seems like it'd be fine to use the number for S1 instead. Any debugger would know the type of the variable anyway, just like if you have a uint16_t in a 64 bit register. x86 puts the value in an XMM register which is along the same lines (maybe there is some special name for XMM as 16 bit elements but I don't know it). Only problem is that the codeview mappings are put into a case statement in one place, so it'll need some refactoring to avoid duplicate values in that. |
LLVM does not properly handle debug info for f16 on the aarch64-windows target, causing "fatal error: unknown codeview register H1". The previous workaround checked only for f16 but was still vulnerable if a type was a byval struct or tuple which had an f16 field in it. Now I have filed an upstream issue (see llvm/llvm-project#56484) and broadened the workaround to always skip debug values for this target.
LLVM does not properly handle debug info for f16 on the aarch64-windows target, causing "fatal error: unknown codeview register H1". The previous workaround checked only for f16 but was still vulnerable if a type was a byval struct or tuple which had an f16 field in it. Now I have filed an upstream issue (see llvm/llvm-project#56484) and broadened the workaround to always skip debug values for this target.
ISTM that Microsoft has mappings for the half precision registers here. |
Thanks! Also now I see from microsoft/microsoft-pdb#51 that that repo isn't up to date. I'll fix the H registers at least. There's also B register mappings but I'm not sure I can get clang to emit them so I'll probably leave them out. |
And there'll be some changes to lldb but separate to the llvm change. |
LLVM does not properly handle debug info for f16 on the aarch64-windows target, causing "fatal error: unknown codeview register H1". The previous workaround checked only for f16 but was still vulnerable if a type was a byval struct or tuple which had an f16 field in it. Now I have filed an upstream issue (see llvm/llvm-project#56484) and broadened the workaround to always skip debug values for this target.
LLVM does not properly handle debug info for f16 on the aarch64-windows target, causing "fatal error: unknown codeview register H1". The previous workaround checked only for f16 but was still vulnerable if a type was a byval struct or tuple which had an f16 field in it. Now I have filed an upstream issue (see llvm/llvm-project#56484) and broadened the workaround to always skip debug values for this target.
Fixes llvm/llvm-project#56484 H registers are 16 bit views of AArch64's Neon registers and B are the 8 bit views. msvc does not support 16 bit float (some mention in DirectX but I couldn't find a way to get to it) so for lack of a better reference I'm using: https://github.com/MicrosoftEdge/JsDbg/blob/85c9b41b33bb8f3496dbe400d912c32bb7cc496b/server/references/dia/include/cvconst.h (the other microsoft-pdb repo is no longer up to date) Luckily clang does support fp16 so a test is added for that. There is no 8 bit float type so I had to get creative with the test case. We're not testing for correct debug info here just that we can select the B register and not crash in the process. For FPCR it's never going to be passed as an argument so I've not added a test for it. It is included to keep our list looking the same as the reference. Reviewed By: majnemer Differential Revision: https://reviews.llvm.org/D129774
Fixes llvm#56484 H registers are 16 bit views of AArch64's Neon registers and B are the 8 bit views. msvc does not support 16 bit float (some mention in DirectX but I couldn't find a way to get to it) so for lack of a better reference I'm using: https://github.com/MicrosoftEdge/JsDbg/blob/85c9b41b33bb8f3496dbe400d912c32bb7cc496b/server/references/dia/include/cvconst.h (the other microsoft-pdb repo is no longer up to date) Luckily clang does support fp16 so a test is added for that. There is no 8 bit float type so I had to get creative with the test case. We're not testing for correct debug info here just that we can select the B register and not crash in the process. For FPCR it's never going to be passed as an argument so I've not added a test for it. It is included to keep our list looking the same as the reference. Reviewed By: majnemer Differential Revision: https://reviews.llvm.org/D129774 (cherry picked from commit 5d14873)
Repro
Tested with 14.0.6.
reduced.ll
The text was updated successfully, but these errors were encountered: