https://sourceware.org/bugzilla/show_bug.cgi?id=29856
--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Indu Bhagat <ibha...@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8c078abdc23238c2193136bf0edbf1d910615679 commit 8c078abdc23238c2193136bf0edbf1d910615679 Author: Indu Bhagat <indu.bha...@oracle.com> Date: Thu Dec 15 13:12:01 2022 -0800 libsframe asan: avoid generating misaligned loads There are two places where unaligned loads were seen on aarch64: - #1. access to the SFrame FRE stack offsets in the in-memory representation/abstraction provided by libsframe. - #2. access to the SFrame FRE start address in the on-disk representation of the frame row entry. For #1, we can fix this by reordering the struct members of sframe_frame_row_entry in libsframe/sframe-api.h. For #2, we need to default to using memcpy instead, and copy out the bytes to a location for output. SFrame format is an unaligned on-disk format. As such, there are other blobs of memory in the on-disk SFrame FRE that are on not on their natural boundaries. But that does not pose further problems yet, because the users are provided access to the on-disk SFrame FRE data via libsframe's sframe_frame_row_entry, the latter has its' struct members aligned on their respective natural boundaries (and initialized using memcpy). PR 29856 libsframe asan: load misaligned at sframe.c:516 ChangeLog: PR libsframe/29856 * bfd/elf64-x86-64.c: Adjust as the struct members have been reordered. * libsframe/sframe.c (sframe_decode_fre_start_address): Use memcpy to perform 16-bit/32-bit reads. * libsframe/testsuite/libsframe.encode/encode-1.c: Adjust as the struct members have been reordered. include/ChangeLog: PR libsframe/29856 * sframe-api.h: Reorder fre_offsets for natural alignment. -- You are receiving this mail because: You are on the CC list for the bug.
