( Resending with correct lldb-commits email address Cc:'ed )
Hi Sagar, I noticed this weekend that given an input program like
int foo (int in) { return in + 5;}
int main (int argc, char**argv) { return foo(argc); }
if I put a breakpoint on foo() on an x86 system (compiled with clang, on a
mac), I get an llvm assert when I backtrace:
(lldb) bt
Assertion failed: (width > BitWidth && "Invalid APInt SignExtend request"),
function sext, file /Users/jason/work/lldb/llvm/lib/Support/APInt.cpp, line 956.
The assert is being hit here -
4 0x000109cbe401 LLDB`__assert_rtn + 129 Signals.inc:517
5 0x000109c39dc8 LLDB`llvm::APInt::sext + 120 APInt.cpp:956
6 0x00010a36687d LLDB`lldb_private::Scalar::Promote + 11725
Scalar.cpp:1166
7 0x00010a36c073 LLDB`PromoteToMaxType + 307 Scalar.cpp:63
8 0x00010a36bd6d LLDB`lldb_private::Scalar::operator+= + 77
Scalar.cpp:2361
9 0x00010a46db4f LLDB`lldb_private::DWARFExpression::Evaluate +
38703 DWARFExpression.cpp:2564
10 0x00010a464399 LLDB`lldb_private::DWARFExpression::Evaluate +
1785 DWARFExpression.cpp:1325
11 0x00010a3fa9e5
LLDB`lldb_private::ValueObjectVariable::UpdateValue + 965
ValueObjectVariable.cpp:166
12 0x00010a3c4ceb
LLDB`lldb_private::ValueObject::UpdateValueIfNeeded + 1483 ValueObject.cpp:236
13 0x00010a3ce0ba
LLDB`lldb_private::ValueObject::GetValueAsCString + 42 ValueObject.cpp:1430
14 0x00010a379edf LLDB`lldb_private::FormatEntity::Format + 18991
FormatEntity.cpp:1800
15 0x00010a375b31 LLDB`lldb_private::FormatEntity::Format + 1665
FormatEntity.cpp:1228
16 0x00010a375b31 LLDB`lldb_private::FormatEntity::Format + 1665
FormatEntity.cpp:1228
17 0x00010a375767 LLDB`lldb_private::FormatEntity::Format + 695
FormatEntity.cpp:1204
18 0x00010aa1bc9b
LLDB`lldb_private::StackFrame::DumpUsingSettingsFormat + 523
StackFrame.cpp:1379
19 0x00010aa1d036 LLDB`lldb_private::StackFrame::GetStatus + 102
StackFrame.cpp:1475
20 0x00010aa25ecd LLDB`lldb_private::StackFrameList::GetStatus +
3037 StackFrameList.cpp:936
The DWARF expression for 'argc' is
0x0000005c: TAG_subprogram [2] *
AT_low_pc( 0x0000000100000f70 )
AT_high_pc( 0x0000000100000fa0 )
AT_frame_base( rbp )
AT_name( "main" )
0x0000007b: TAG_formal_parameter [3]
AT_location( fbreg -8 )
We create a Scalar object to represent the frame base value, lldb type s_ulong,
APInt BitWidth 64, in DWARFExpression::Evaluate():
2561 if (frame->GetFrameBaseValue(value, error_ptr))
2562 {
2563 int64_t fbreg_offset =
opcodes.GetSLEB128(&offset);
-> 2564 value += fbreg_offset;
So we're adding a e_slonglong (64-bit signed value, -8) to an e_ulong (64-bit
unsigned, 0x00007fff5fbffb10).
We end up in Scalar::Promote, trying to promote the 64-bit e_ulong APInt to a
64-bit e_slonglong APInt:
1152 case e_ulong:
1153 switch (type)
1154 {
1164 case e_slonglong:
1165 {
-> 1166 m_integer = m_integer.sext(sizeof(slonglong_t)
* 8);
1167 success = true;
1168 break;
and APInt::sext() asserts because the unsigned and the signed types have the
same bit width.
NB if I stop in main() itself, Frame::GetFrameBaseValue() happens to return a
Scalar frame base value of e_ulonglong (still 64-bits) for the frame base
value. This means that Scalar::Promote instead creates a new APInt object
instead of trying to sign extend:
1225 case e_ulonglong:
1226 {
-> 1227 m_integer = llvm::APInt(sizeof(ulonglong_t) * 8,
*(const uint64_t *)m_integer.getRawData(), false);
and it works as expected. For whatever reason, when we retrieve the frame base
value higher up on the stack, we are getting an e_ulong (64-bits) which is when
we have problems.
J
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
