about summary refs log tree commit diff
path: root/src/rustllvm/ExecutionEngineWrapper.cpp
diff options
context:
space:
mode:
authorAlex Crichton <alex@alexcrichton.com>2014-04-03 10:45:36 -0700
committerAlex Crichton <alex@alexcrichton.com>2014-04-03 10:49:35 -0700
commit15e6e8cf3e6b06a79968c2c4d3eadad5729f74e1 (patch)
treec8d1317a88ebdcac6ce0e5f2c86456ae839ef7a7 /src/rustllvm/ExecutionEngineWrapper.cpp
parent6f1c06d6a1b97fcd80d85c38bb33f8350c750401 (diff)
downloadrust-15e6e8cf3e6b06a79968c2c4d3eadad5729f74e1.tar.gz
rust-15e6e8cf3e6b06a79968c2c4d3eadad5729f74e1.zip
rustc: Stop using LLVMGetSectionName
The recent pull request to remove libc from libstd has hit a wall in compiling
on windows, and I've been trying to investigate on the try bots as to why (it
compiles locally just fine). To the best of my knowledge, the LLVM section
iterator is behaving badly when iterating over the sections of the libc DLL.

Upon investigating the LLVMGetSectionName function in LLVM, I discovered that
this function doesn't always return a null-terminated string. It returns the
data pointer of a StringRef instance (LLVM's equivalent of &str essentially),
but it has no method of returning the length of the name of the section.

This commit modifies the section iteration when loading libraries to invoke a
custom LLVMRustGetSectionName which will correctly return both the length and
the data pointer.

I have not yet verified that this will fix landing liblibc, as it will require a
snapshot before doing a full test. Regardless, this is a worrisome situation
regarding the LLVM API, and should likely be fixed anyway.
Diffstat (limited to 'src/rustllvm/ExecutionEngineWrapper.cpp')
0 files changed, 0 insertions, 0 deletions