[PATCH] Initialize memory groups once any is initialized.
Lang Hames via llvm-commits
llvm-commits at lists.llvm.org
Mon Jul 13 13:28:22 PDT 2020
Hi Dana,
Thanks for your patience. This looks good to me. Do you have commit access,
or would you like me to commit on your behalf?
Regards,
Lang.
On Mon, Jun 29, 2020 at 1:20 PM Dana Koch <dsk at google.com> wrote:
> JITted code may include relocations between sections, and the
> relocations often chosen to do this are 32-bit PC-relative relocation
> types. Thus, consideration must be made to ensure sections are allocated
> sufficiently close to one another.
>
> The SectionMemoryManager provides three memory groups, one for Code
> data, one for ROData, and one for RWdata. Sections are allocated with
> mmap (via allocateMappedMemory) which allows the caller to provide a
> hint to the system to suggest where to position mmap'ped memory. A
> memory group has a Near block which lets successive allocations to that
> memory group be positioned near other mappings in that group via the
> mmap hint. Initially, this Near block is empty, that is, its address is
> nullptr. When mmap is passed a nullptr hint, the system may choose any
> location to position the mapping.
>
> This means, prior to this commit, the first Code section mapping, ROData
> section mapping, and RWData section mapping will all be placed at a
> location of the system's choosing, and the system may choose distant
> enough locations in memory such that a 32-bit PC-relative relocation
> would overflow.
>
> Therefore, once allocateMappedMemory allocates the first mapping, copy
> that Near block hint to the other memory groups. This ensures that
> sections are allocated close to another so relative relocations are less
> likely to overflow.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200713/85904651/attachment.html>
More information about the llvm-commits
mailing list