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

[Filip Pizlo]

On Oct 1, 2013, at 4:24 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote:

> Hi Filip,
>  
> This looks good.  Can you document the new parameter in the comments, at least in RTDyldMemoryManager.h

Oh, right - will do!

> , and mention the fact that multiple sections may be allocated with the same name?  That will definitely happen with multiple module support.

Good point!  Yeah, I'll do that.

>  
> Thanks for the patch!  I’ve already got a use in mind for it.
>  
> -Andy
>  
> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Filip Pizlo
> Sent: Tuesday, October 01, 2013 4:10 PM
> To: llvm-commits at cs.uiuc.edu
> Subject: [PATCH] JIT/RTDyld memory managers should know section names
>  
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131001/46221494/attachment.html>