[PATCH] Initialize memory groups once any is initialized.

[Lang Hames via llvm-commits]

Hi Dana,

Committed as
https://github.com/llvm/llvm-project/commit/574713c3076c11a5677f554ab132d1324be9cb00
.

Thanks again for the patch!

Regards,
Lang.

On Fri, Jul 17, 2020 at 11:47 AM Dana Koch <dsk at google.com> wrote:

> Please commit on my behalf. Thanks!
>
> On Mon, Jul 13, 2020 at 4:28 PM Lang Hames <lhames at gmail.com> wrote:
> >
> > 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/20200720/69b531c9/attachment.html>