[Bug ld/14718] ld crashes on ARMv5 due to unaligned memory access
http://sourceware.org/bugzilla/show_bug.cgi?id=14718 Siarhei Siamashka changed: What|Removed |Added CC||siarhei.siamashka at gmail ||dot com --- Comment #5 from Siarhei Siamashka 2012-10-14 20:57:41 UTC --- Or maybe changing the order like this: diff --git a/bfd/elf32-arm.c b/bfd/elf32-arm.c index 633bb64..0efcf1d 100644 --- a/bfd/elf32-arm.c +++ b/bfd/elf32-arm.c @@ -3061,12 +3061,12 @@ elf32_arm_allocate_local_sym_info (bfd *abfd) elf_local_got_refcounts (abfd) = (bfd_signed_vma *) data; data += num_syms * sizeof (bfd_signed_vma); - elf32_arm_local_iplt (abfd) = (struct arm_local_iplt_info **) data; - data += num_syms * sizeof (struct arm_local_iplt_info *); - elf32_arm_local_tlsdesc_gotent (abfd) = (bfd_vma *) data; data += num_syms * sizeof (bfd_vma); + elf32_arm_local_iplt (abfd) = (struct arm_local_iplt_info **) data; + data += num_syms * sizeof (struct arm_local_iplt_info *); + elf32_arm_local_got_tls_type (abfd) = data; } return TRUE; Because in the current code bfd_signed_vma array (64-bit elements) is followed by arm_local_iplt_info * array (32-bit elements) and then followed by bfd_vma array (64-bit elements again). If num_syms is odd, then the last array is not 64-bit aligned. Just swapping the order of the second and third arrays might help. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/14718] ld crashes on ARMv5 due to unaligned memory access
http://sourceware.org/bugzilla/show_bug.cgi?id=14718 --- Comment #7 from Siarhei Siamashka 2012-10-14 22:32:12 UTC --- (In reply to comment #5) > Because in the current code bfd_signed_vma array (64-bit elements) is followed > by arm_local_iplt_info * array (32-bit elements) and then followed by bfd_vma > array (64-bit elements again). If num_syms is odd, then the last array is not > 64-bit aligned. Just swapping the order of the second and third arrays might > help. Hmm, this is beginning to be really funny. My gentoo arm system has "#define BFD_ARCH_SIZE 64" line in /usr/include/bfd.h, resulting in 64-bit vma typedefs. I guess such weird configuration is a prerequisite for triggering this alignment issue. The culprit is gentoo toolchain-binutils.eclass which is forcing --enable-64-bit-bfd configure option. The architectures like ARM surely have lots of spare RAM to waste... Looks like at least this part of the problem needs to be solved on gentoo side. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/14718] ld crashes on ARMv5 due to unaligned memory access
http://sourceware.org/bugzilla/show_bug.cgi?id=14718 --- Comment #9 from Siarhei Siamashka 2012-10-14 22:50:44 UTC --- (In reply to comment #6) > I would be very careful with swapping because the size of the > arm_local_iplt_info* is unknown (could be 64-bit or anything). It would still > work, but just by accident, because we would allocate 2*num_syms of 32-bit > objects first, making sure the 64-bit pointers that follow are aligned. Thanks for pointing this. Indeed, the sizes of vma typedefs and the sizes of pointers can make some really weird combinations. > So I strongly prefer the manual alignment approach; it's unlikely that > a small change in the code would break it. This or the suggestion from Andreas Schwab with separate allocations. One nitpick about your patch is the unnecessary realignment for the char array (sizeof(char) is always 1). -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
