| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 191938
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 191804
|
|
|
|
|
|
|
| |
were not provided.
FIXME: Would it be responsible to provide GOT?
llvm-svn: 188855
|
|
|
|
| |
llvm-svn: 181354
|
|
|
|
|
|
| |
This changes the RecordingMemoryManager in lli to use mapped memory rather than malloc to allocate memory for sections and uses a 'near' MemoryBlock to keep the allocations together. This works around a problem in MCJIT where relocations are applied to a generated image immediately oupon generation, which isn't appropriate for the remote case.
llvm-svn: 176057
|
|
|
|
|
|
|
| |
satisfy --vg-leak!
FIXME: It could be generalized in MemoryManager.
llvm-svn: 173349
|
|
|
|
|
|
|
|
| |
emitted in @main().
XFAIL(s) can be removed.
llvm-svn: 168282
|
|
|
|
|
|
| |
permissions after an object has been loaded.
llvm-svn: 168114
|
|
Simulate a remote target address space by allocating a seperate chunk of
memory for the target and re-mapping section addresses to that prior to
execution. Later we'll want to have a truly remote process, but for now
this gets us closer to being able to test the remote target
functionality outside LLDB.
rdar://12157052
llvm-svn: 163216
|