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

Alexey Samsonov vonosmas at gmail.com
Wed Aug 20 16:03:25 PDT 2014


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>


More information about the llvm-dev mailing list