aboutsummaryrefslogtreecommitdiffstats
path: root/include/llvm-c
diff options
context:
space:
mode:
authorFilip Pizlo <fpizlo@apple.com>2013-10-02 00:59:25 +0000
committerFilip Pizlo <fpizlo@apple.com>2013-10-02 00:59:25 +0000
commit6eb43d295625cd2ff314c59b49d4fd11f3348cad (patch)
treedaec0d82ea11d026745a572949f7c7c1e6e8d5c0 /include/llvm-c
parent2b53089bd017139f0125b870ace94ff27dffd2ff (diff)
downloadexternal_llvm-6eb43d295625cd2ff314c59b49d4fd11f3348cad.zip
external_llvm-6eb43d295625cd2ff314c59b49d4fd11f3348cad.tar.gz
external_llvm-6eb43d295625cd2ff314c59b49d4fd11f3348cad.tar.bz2
This 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 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). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191804 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'include/llvm-c')
-rw-r--r--include/llvm-c/ExecutionEngine.h15
1 files changed, 8 insertions, 7 deletions
diff --git a/include/llvm-c/ExecutionEngine.h b/include/llvm-c/ExecutionEngine.h
index cf3565c..4e767b2 100644
--- a/include/llvm-c/ExecutionEngine.h
+++ b/include/llvm-c/ExecutionEngine.h
@@ -171,13 +171,14 @@ void *LLVMGetPointerToGlobal(LLVMExecutionEngineRef EE, LLVMValueRef Global);
/*===-- Operations on memory managers -------------------------------------===*/
-typedef uint8_t *(*LLVMMemoryManagerAllocateCodeSectionCallback)(void *Opaque,
- uintptr_t Size, unsigned Alignment,
- unsigned SectionID);
-typedef uint8_t *(*LLVMMemoryManagerAllocateDataSectionCallback)(void *Opaque,
- uintptr_t Size, unsigned Alignment,
- unsigned SectionID, LLVMBool IsReadOnly);
-typedef LLVMBool (*LLVMMemoryManagerFinalizeMemoryCallback)(void *Opaque, char **ErrMsg);
+typedef uint8_t *(*LLVMMemoryManagerAllocateCodeSectionCallback)(
+ void *Opaque, uintptr_t Size, unsigned Alignment, unsigned SectionID,
+ const char *SectionName);
+typedef uint8_t *(*LLVMMemoryManagerAllocateDataSectionCallback)(
+ void *Opaque, uintptr_t Size, unsigned Alignment, unsigned SectionID,
+ const char *SectionName, LLVMBool IsReadOnly);
+typedef LLVMBool (*LLVMMemoryManagerFinalizeMemoryCallback)(
+ void *Opaque, char **ErrMsg);
typedef void (*LLVMMemoryManagerDestroyCallback)(void *Opaque);
/**