[PATCH] JIT/RTDyld memory managers should know section names

[Kaylor, Andrew]

The use I had in mind is special handling of ".got" sections.  Right now, RuntimeDyldELF is allocating one GOT section per module, but I'd like to do something to combine the GOT tables in the case where we're handling many small modules.  What I was thinking was that I'd allocate GOT memory in one page increments as needed, but if the memory manager isn't in on this scheme it's likely to start my request in the middle of some other page of data, thus rendering my size selection meaningless.

Of course I'll still need to do something to make sure the GOTs don't stray too far from the rest of the sections, but that's a separate issue.

-Andy

-----Original Message-----
From: Eric Christopher [mailto:echristo at gmail.com] 
Sent: Tuesday, October 01, 2013 4:28 PM
To: Filip Pizlo; Kaylor, Andrew
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [PATCH] JIT/RTDyld memory managers should know section names

Or even better, either of you :)

-eric

On Tue, Oct 1, 2013 at 4:26 PM, Eric Christopher <echristo at gmail.com> wrote:
> Can you give some examples of how you'd like to use this?
>
> -eric
>
> On Tue, Oct 1, 2013 at 4:10 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>> This patch threads SectionName through the allocateCodeSection/allocateDataSection APIs, both in C++ and C land.  It's useful for the memory managers that are allocating a section to know what the name of the section is.  At a minimum, this is extremely useful for low-level debugging - it's customary for JITs to be able to tell you what memory they allocated, and as part of any such dump, they should be able to tell you some meta-data about what each allocation is for.  This allows clients that supply their own memory managers to do this.  Additionally, we also envision the SectionName being useful for passing meta-data from within LLVM to an LLVM client.
>>
>> This changes both the C and C++ APIs, and all of the clients of those APIs within LLVM.  I'm assuming that it's safe to change the C++ API because that API is allowed to change.  I'm assuming that it's safe to change the C API because we haven't shipped the API in a release yet (LLVM 3.3 doesn't include the MCJIT memory management C API).
>>
>> -Filip
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>