-
Notifications
You must be signed in to change notification settings - Fork 13.4k
llvm-readobj reads incorrect values from AMD note property on big-endian hosts #65280
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-backend-amdgpu |
Avoids issues on big-endian hosts. Fixes llvm#65280
Thanks @Pierre-vh , I'll let you know when I check it: don't have an immediate access to a big-endian system right now, so I'll check the fix a bit later. |
I think it's OK to just merge the PR now and assume it's fixed |
Should avoid issues on big-endian hosts. Note that we use aligned types because primitive integers are also aligned. If we don't use aligned types, `HSAILProperties` ends up being 11 bytes instead of 12 (1 byte padding at the end of the struct added by the compiler). Technically only the first type needs to be aligned, but I just used aligned types everywhere to be consistent. Fixes #65280
It's indeed fixed, we had a XFAIL on big endian for the note reading test and it passed, so a buildbot complained. I didn't even know we had a BE buildbot, nice! :) |
…70775) Should avoid issues on big-endian hosts. Note that we use aligned types because primitive integers are also aligned. If we don't use aligned types, `HSAILProperties` ends up being 11 bytes instead of 12 (1 byte padding at the end of the struct added by the compiler). Technically only the first type needs to be aligned, but I just used aligned types everywhere to be consistent. Fixes llvm#65280
getAMDNote
function from llvm/tools/llvm-readobj/ELFDumper.cpp fails to read values from the AMD note properly on big-endian hosts. This is result ofreinterpret_cast
which is followed by reading integers without proper handling of different endianness.Possible fix might include use of a special wrapper for integers which handles different endianness implicitly, like
support::detail::packed_endian_specific_integral
.The text was updated successfully, but these errors were encountered: