llvm dev - Aug 2014 - [LLVMdev] [RFC] Adding functions for unaligned load/store to Support for JIT/RuntimeDyld

Hi,

I've noticed that certain parts of LLVM (RuntimeDyld, JIT) use unaligned
memory accesses to load/store pointers or just 32- or 64-bit integers.
Technically, this is undefined behavior, and UBSan reports errors when this
happens. Even if we believe we're running some x86-specific code (e.g.
RuntimeDyldELF::resolveX86_64Relocation) what matters for unaligned acceses
in source code is the host architecture, not the target one.

What do you think of adding

  T unaligned_load(const void *addr)
  void unaligned_store(void *addr, T value);

to support headers? We can then provide the default memcpy implementations
of these methods and, optionally, straightforward implementations for x86
hosts (and disable UBSan alignment checks for the latter).

-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140819/67b5bf2f/attachment.html>

Hi Alexey,

That sounds good to me. RuntimeDyldMachO already has writeBytesUnaligned
for this reason, though it's use is somewhat patchy. We should also make
better use of the facilities provided in llvm/Support/Endian.h - it has
alignment and endianness aware definitions for common primitive types.

Cheers,
Lang.


On Tue, Aug 19, 2014 at 4:40 PM, Alexey Samsonov <vonosmas at gmail.com>
wrote:
> Hi,
>
> I've noticed that certain parts of LLVM (RuntimeDyld, JIT) use
unaligned
> memory accesses to load/store pointers or just 32- or 64-bit integers.
> Technically, this is undefined behavior, and UBSan reports errors when this
> happens. Even if we believe we're running some x86-specific code (e.g.
> RuntimeDyldELF::resolveX86_64Relocation) what matters for unaligned acceses
> in source code is the host architecture, not the target one.
>
> What do you think of adding
>
>   T unaligned_load(const void *addr)
>   void unaligned_store(void *addr, T value);
>
> to support headers? We can then provide the default memcpy implementations
> of these methods and, optionally, straightforward implementations for x86
> hosts (and disable UBSan alignment checks for the latter).
>
> --
> Alexey Samsonov
> vonosmas at gmail.com
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140820/20bd136e/attachment.html>

Hi Lang,


On Wed, Aug 20, 2014 at 12:04 PM, Lang Hames <lhames at gmail.com> wrote:
> Hi Alexey,
>
> That sounds good to me. RuntimeDyldMachO already has writeBytesUnaligned
> for this reason, though it's use is somewhat patchy. We should also
make
> better use of the facilities provided in llvm/Support/Endian.h - it has
> alignment and endianness aware definitions for common primitive types.
>
Cool, thanks. Looks like Endian.h already has read/write methods with
configurable alignment. I'll try to plug them into ExecutionEngine then.

>
> Cheers,
> Lang.
>
>
> On Tue, Aug 19, 2014 at 4:40 PM, Alexey Samsonov <vonosmas at
gmail.com>
> wrote:
>
>> Hi,
>>
>> I've noticed that certain parts of LLVM (RuntimeDyld, JIT) use
unaligned
>> memory accesses to load/store pointers or just 32- or 64-bit integers.
>> Technically, this is undefined behavior, and UBSan reports errors when
this
>> happens. Even if we believe we're running some x86-specific code
(e.g.
>> RuntimeDyldELF::resolveX86_64Relocation) what matters for unaligned
acceses
>> in source code is the host architecture, not the target one.
>>
>> What do you think of adding
>>
>>   T unaligned_load(const void *addr)
>>   void unaligned_store(void *addr, T value);
>>
>> to support headers? We can then provide the default memcpy
>> implementations of these methods and, optionally, straightforward
>> implementations for x86 hosts (and disable UBSan alignment checks for
the
>> latter).
>>
>> --
>> Alexey Samsonov
>> vonosmas at gmail.com
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>

-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140820/354bc548/attachment.html>