Hi,
I have problem with IRBuilderBase::InsertPointGuard class that simply does
not work in the release build of my project. The class does not restore the
IRBuilder's insert point correctly when NDEBUG macro is set. It happens on
OSX system only, trunk version of the LLVM built with brew.
I suspect it is the ABI problem. InsertPointGuard uses AssertingVT for
debug builds.
LLDB gets confused also. The first listing shows that the instance of
InsertPointGuard is messed up:
96 auto check = _builder.GetInsertBlock();
97 {
98 llvm::IRBuilderBase::InsertPointGuard guard{_builder};
-> 99 _builder.SetInsertPoint(checkBB);
100 }
101
102 if (_builder.GetInsertBlock() != check)
(lldb) p _builder
(llvm::IRBuilder<true, llvm::ConstantFolder,
llvm::IRBuilderDefaultInserter<true> >) $4 = {
llvm::IRBuilderBase = {
CurDbgLocation = {
Loc = {
Ref = {
MD = 0x0000000000000000
}
}
}
BB = 0x000000010642ecf0
InsertPt = {
NodePtr = 0x000000010642ed00
}
Context = 0x000000010642d170
DefaultFPMathTag = 0x0000000000000000
FMF = (Flags = 0)
}
Folder = {}
}
(lldb) p guard
(llvm::IRBuilderBase::InsertPointGuard) $5 = {
Builder = 0x00007fff5fbf46d8
Block = {
ThePtr = 0x0000000107800398
}
Point = {
NodePtr = 0x0000000000000000
}
DbgLoc = {
Loc = {
Ref = {
MD = 0x000000010642ecf0
}
}
}
}
Moreover, if I start printing the guard from InsertPointGuard constructor
it shows different data layout. LLDB also crashes after step out and
printing the guard again.
195 public:
196 InsertPointGuard(IRBuilderBase &B)
197 : Builder(B), Block(B.GetInsertBlock()),
Point(B.GetInsertPoint()),
-> 198 DbgLoc(B.getCurrentDebugLocation()) {}
199
200 ~InsertPointGuard() {
201 Builder.restoreIP(InsertPoint(Block, Point));
(lldb) p *this
(llvm::IRBuilderBase::InsertPointGuard) $6 = {
Builder = 0x00007fff5fbf4440
Block = {
llvm::ValueHandleBase = {
PrevPair = (Value = 4337803886)
Next = 0x000000010615b0a8
V = 0x000000010615b170
}
}
Point = {
NodePtr = 0x000000010615b140
}
DbgLoc = {
Loc = {
Ref = {
MD = 0x000000010324444b
}
}
}
}
(lldb) n
Process 1498 stopped
* thread #1: tid = 0x493aa8, 0x0000000102920b22
libevmjit.0.0.dylib`dev::eth::jit::test(_builder=0x00007fff5fbf46d8) + 258
at RuntimeManager.cpp:99, queue = 'com.apple.main-thread', stop reason
step over
frame #0: 0x0000000102920b22
libevmjit.0.0.dylib`dev::eth::jit::test(_builder=0x00007fff5fbf46d8) + 258
at RuntimeManager.cpp:99
96 auto check = _builder.GetInsertBlock();
97 {
98 llvm::IRBuilderBase::InsertPointGuard guard{_builder};
-> 99 _builder.SetInsertPoint(checkBB);
100 }
101
102 if (_builder.GetInsertBlock() != check)
(lldb) p guard
Assertion failed: (field_idx < record_layout.getFieldCount()), function
GetChildClangTypeAtIndex, file
/SourceCache/lldb/lldb-320.4.156/source/Symbol/ClangASTType.cpp, line 6615.
Abort trap: 6
It's hard to create a small executable where the problem can be reproduced.
Cheers,
- Paweł Bylica
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150713/af0c77e9/attachment.html>
The layout of AssertingVH has depended on NDEBUG since 2009, which predates any of our efforts to make LLVM's ABI resilient to mismatched NDEBUG definitions between LLVM and its users. For now, make sure your definition of NDEBUG matches LLVM's. In the long run, we could conceivably do something with LLVM_ENABLE_ABI_BREAKING_CHECKS to allow this mismatch. On Mon, Jul 13, 2015 at 6:39 AM, Paweł Bylica <chfast at gmail.com> wrote:> Hi, > > I have problem with IRBuilderBase::InsertPointGuard class that simply does > not work in the release build of my project. The class does not restore the > IRBuilder's insert point correctly when NDEBUG macro is set. It happens on > OSX system only, trunk version of the LLVM built with brew. > > I suspect it is the ABI problem. InsertPointGuard uses AssertingVT for > debug builds. > > LLDB gets confused also. The first listing shows that the instance of > InsertPointGuard is messed up: > > 96 auto check = _builder.GetInsertBlock(); > 97 { > 98 llvm::IRBuilderBase::InsertPointGuard guard{_builder}; > -> 99 _builder.SetInsertPoint(checkBB); > 100 } > 101 > 102 if (_builder.GetInsertBlock() != check) > (lldb) p _builder > (llvm::IRBuilder<true, llvm::ConstantFolder, > llvm::IRBuilderDefaultInserter<true> >) $4 = { > llvm::IRBuilderBase = { > CurDbgLocation = { > Loc = { > Ref = { > MD = 0x0000000000000000 > } > } > } > BB = 0x000000010642ecf0 > InsertPt = { > NodePtr = 0x000000010642ed00 > } > Context = 0x000000010642d170 > DefaultFPMathTag = 0x0000000000000000 > FMF = (Flags = 0) > } > Folder = {} > } > (lldb) p guard > (llvm::IRBuilderBase::InsertPointGuard) $5 = { > Builder = 0x00007fff5fbf46d8 > Block = { > ThePtr = 0x0000000107800398 > } > Point = { > NodePtr = 0x0000000000000000 > } > DbgLoc = { > Loc = { > Ref = { > MD = 0x000000010642ecf0 > } > } > } > } > > Moreover, if I start printing the guard from InsertPointGuard constructor > it shows different data layout. LLDB also crashes after step out and > printing the guard again. > > 195 public: > 196 InsertPointGuard(IRBuilderBase &B) > 197 : Builder(B), Block(B.GetInsertBlock()), > Point(B.GetInsertPoint()), > -> 198 DbgLoc(B.getCurrentDebugLocation()) {} > 199 > 200 ~InsertPointGuard() { > 201 Builder.restoreIP(InsertPoint(Block, Point)); > (lldb) p *this > (llvm::IRBuilderBase::InsertPointGuard) $6 = { > Builder = 0x00007fff5fbf4440 > Block = { > llvm::ValueHandleBase = { > PrevPair = (Value = 4337803886) > Next = 0x000000010615b0a8 > V = 0x000000010615b170 > } > } > Point = { > NodePtr = 0x000000010615b140 > } > DbgLoc = { > Loc = { > Ref = { > MD = 0x000000010324444b > } > } > } > } > (lldb) n > Process 1498 stopped > * thread #1: tid = 0x493aa8, 0x0000000102920b22 > libevmjit.0.0.dylib`dev::eth::jit::test(_builder=0x00007fff5fbf46d8) + 258 > at RuntimeManager.cpp:99, queue = 'com.apple.main-thread', stop reason > step over > frame #0: 0x0000000102920b22 > libevmjit.0.0.dylib`dev::eth::jit::test(_builder=0x00007fff5fbf46d8) + 258 > at RuntimeManager.cpp:99 > 96 auto check = _builder.GetInsertBlock(); > 97 { > 98 llvm::IRBuilderBase::InsertPointGuard guard{_builder}; > -> 99 _builder.SetInsertPoint(checkBB); > 100 } > 101 > 102 if (_builder.GetInsertBlock() != check) > (lldb) p guard > Assertion failed: (field_idx < record_layout.getFieldCount()), function > GetChildClangTypeAtIndex, file > /SourceCache/lldb/lldb-320.4.156/source/Symbol/ClangASTType.cpp, line 6615. > Abort trap: 6 > > It's hard to create a small executable where the problem can be reproduced. > > Cheers, > - Paweł Bylica > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150713/ac894fbd/attachment.html>
I can confirm that the issue has been caused by NDEBUG flag. On Mon, Jul 13, 2015 at 6:29 PM Reid Kleckner <rnk at google.com> wrote:> The layout of AssertingVH has depended on NDEBUG since 2009, which > predates any of our efforts to make LLVM's ABI resilient to mismatched > NDEBUG definitions between LLVM and its users. > > For now, make sure your definition of NDEBUG matches LLVM's. In the long > run, we could conceivably do something with LLVM_ENABLE_ABI_BREAKING_CHECKS > to allow this mismatch. >In practice it is very hard to make NDEBUG flag match configs of your project and LLVM project. You often need to build debug and release versions of your project and LLVM is installed as a debian package or with homebrew. Moreover, there is not reliable way of checking if LLVM has been built with or without NDEBUG. Can I do anything more about it? Contributions related to LLVM_ENABLE_ABI_BREAKING_CHECKS needed? - Paweł -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150721/fdc8672d/attachment.html>