This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [patch] Use unaligned access on x86_64
- From: Rafael EspÃndola <rafael dot espindola at gmail dot com>
- To: Cary Coutant <ccoutant at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Wed, 3 Jun 2015 11:31:47 -0400
- Subject: Re: [patch] Use unaligned access on x86_64
- Authentication-results: sourceware.org; auth=none
- References: <CAG3jRe+iwbjGWdqG-0gTb-8yNWqDN=S-1iVLkNKP2cXEscONhA at mail dot gmail dot com> <CAJimCsGZmT=0egTKyz96LgJOFmoaZFwE7oAb12pX+fVgPA+cZA at mail dot gmail dot com> <CAG3jReLcKRAhBbCCo4FzzoP+xyZaT3x4bEokhfEPAe36x1fvBg at mail dot gmail dot com> <CAG3jReJKO3Rk_d+CwYUgt21CF=CmiShFGhfVGs_r2dsKPwiLAQ at mail dot gmail dot com> <CAJimCsFRW0Pwq-DOFpEAvEw2iwXF7CMdb-mytWvFm_Spg8qkOA at mail dot gmail dot com> <CAG3jReJpxWzQEGW1Xwyh0SE1RSG2rcYUjuCGnd1QNCQj+69ZLw at mail dot gmail dot com>
On 3 June 2015 at 01:56, Rafael EspÃndola <rafael.espindola@gmail.com> wrote:
>> Oops, that looks like a bug in nacl.h: the Sniff_file class calls
>> get_view(0, file_offset, ...) instead of get_view(file_offset, 0,
>> ...). That will only get a view that's aligned for offset 0, rather
>> than a view that's aligned at file_offset.
>
> With your fix I now only get on invalid access (store) when linking clang:
>
> #0 __ubsan_handle_type_mismatch () at
> /home/espindola/llvm/llvm/projects/compiler-rt/lib/ubsan/ubsan_handlers.cc:72
> #1 0x00000000004eb8cf in elfcpp::Swap<32, false>::writeval
> (wv=0x7fffde4d30cf, v=52614397) at
> ../../binutils/gold/../elfcpp/elfcpp_swap.h:237
> #2 0x000000000056f669 in gold::Relocate_functions<64,
> false>::pcrela<32> (view=0x7fffde4d30cf "", value=59729360,
> addend=4294967292, address=7114959) at ../../binutils/gold/reloc.h:461
> #3 0x000000000056f0f9 in gold::Relocate_functions<64,
> false>::pcrela32 (view=0x7fffde4d30cf "", value=59729360,
> addend=4294967292, address=7114959) at ../../binutils/gold/reloc.h:652
> #4 0x0000000000528f80 in (anonymous
> namespace)::Target_x86_64<64>::Relocate::relocate
> (this=0x7fffffff4b10, relinfo=0x7fffffff5040, target=0x3a59c30,
> relnum=0, rela=..., r_type=9, gsym=0x3a5bfb0, psymval=0x7fffffff4aa0,
> view=0x7fffde4d30cf "", address=7114959, view_size=21)
> at ../../binutils/gold/x86_64.cc:3572
> #5 0x00000000005265cf in gold::relocate_section<64, false, (anonymous
> namespace)::Target_x86_64<64>, 4, (anonymous
> namespace)::Target_x86_64<64>::Relocate,
> gold::Default_comdat_behavior> (relinfo=0x7fffffff5040,
> target=0x3a59c30, prelocs=0x7ffff7fef4b0 "\a", reloc_count=2,
> output_section=
> 0x3a5a300, needs_special_offset_handling=false,
> view=0x7fffde4d30c8 "H\203\354\bH\213\005", view_address=7114952,
> view_size=21, reloc_symbol_changes=0x0) at
> ../../binutils/gold/target-reloc.h:403
> #6 0x00000000005091ec in (anonymous
> namespace)::Target_x86_64<64>::relocate_section (this=0x3a59c30,
> relinfo=0x7fffffff5040, sh_type=4, prelocs=0x7ffff7fef4b0 "\a",
> reloc_count=2, output_section=0x3a5a300,
> needs_special_offset_handling=false, view=0x7fffde4d30c8
> "H\203\354\bH\213\005",
> address=7114952, view_size=21, reloc_symbol_changes=0x0) at
> ../../binutils/gold/x86_64.cc:4248
> #7 0x00000000012e1b24 in gold::Sized_relobj_file<64,
> false>::do_relocate_sections (this=0x3a5b630, symtab=0x7fffffff6198,
> layout=0x7fffffff5d48, pshdrs=0x7ffff7fef0b0 "", of=0xab3eaf0,
> pviews=0x7fffffff5318) at ../../binutils/gold/reloc.cc:1013
> #8 0x000000000106fcf1 in gold::Sized_relobj_file<64,
> false>::relocate_sections (this=0x3a5b630, symtab=0x7fffffff6198,
> layout=0x7fffffff5d48, pshdrs=0x7ffff7fef0b0 "", of=0xab3eaf0,
> pviews=0x7fffffff5318) at ../../binutils/gold/object.h:2546
> #9 0x00000000012d3b41 in gold::Sized_relobj_file<64,
> false>::do_relocate (this=0x3a5b630, symtab=0x7fffffff6198,
> layout=0x7fffffff5d48, of=0xab3eaf0) at
> ../../binutils/gold/reloc.cc:670
> #10 0x00000000012ea851 in gold::Relobj::relocate (this=0x3a5b630,
> symtab=0x7fffffff6198, layout=0x7fffffff5d48, of=0xab3eaf0) at
> ../../binutils/gold/object.h:1185
> #11 0x00000000012b6b12 in gold::Relocate_task::run (this=0xa33fbd0) at
> ../../binutils/gold/reloc.cc:239
> #12 0x00000000014dde8d in gold::Workqueue::find_and_run_task
> (this=0x7fffffff65d8, thread_number=0) at
> ../../binutils/gold/workqueue.cc:319
> #13 0x00000000014df23f in gold::Workqueue::process
> (this=0x7fffffff65d8, thread_number=0) at
> ../../binutils/gold/workqueue.cc:495
> #14 0x0000000000421d37 in main (argc=203, argv=0x7fffffffc3c8) at
> ../../binutils/gold/main.cc:252
his looks like a case where we really have to do an unaligned write
because of the X86 instructions.
The attached patch makes it a legal unaligned write. What do you think?
Cheers,
Rafael
diff --git a/elfcpp/elfcpp_swap.h b/elfcpp/elfcpp_swap.h
index 5b9a915..cddc0b3 100644
--- a/elfcpp/elfcpp_swap.h
+++ b/elfcpp/elfcpp_swap.h
@@ -234,7 +234,10 @@ struct Swap
static inline void
writeval(Valtype* wv, Valtype v)
- { *wv = Convert<size, big_endian>::convert_host(v); }
+ {
+ Valtype T = Convert<size, big_endian>::convert_host(v);
+ memcpy(wv, &T, sizeof(T));
+ }
static inline Valtype
readval(const unsigned char* wv)