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

[Jim Grosbach]

Also consider start-up code in a system that doesn’t have an interpreter. That could go in a separate section, so the memory manager can then free it all once its run and done its job while still keeping the rest of the code around. Special section names are a typical way things like that are communicated to linkers and loaders in the non-JIT world, so it’s easiest to keep with that pattern here since we’re trying to minimize the differences between static and dynamic compilation models.

I was originally planning, way back when, to keep the names private thinking that any special logic about that stuff would be internal to the MCJIT itself. I’ve since come to my senses a bit and believe there’s good value to exposing the information for the client application to be able to do context-sensitive things.

-Jim

On Oct 1, 2013, at 4:54 PM, Eric Christopher <echristo at gmail.com> wrote:

> *nod* That's fairly useful.
> 
> -eric
> 
> On Tue, Oct 1, 2013 at 4:44 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote:
>> 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
>>>> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits