[LLVMdev] [RFC] Adding functions for unaligned load/store to Support for JIT/RuntimeDyld

[Lang Hames]

Excellent. Thank you for looking in to this.

- Lang.


On Wed, Aug 20, 2014 at 4:03 PM, Alexey Samsonov <vonosmas at gmail.com> wrote:

> 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/02bca337/attachment.html>