<html>
<head>
<base href="http://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - LLDB needs DW_TAG_template_type_param to interpret a DW_TAG_structure_type as template instanciation. GCC and clang omit this in some cases though."
href="http://llvm.org/bugs/show_bug.cgi?id=20455">20455</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>LLDB needs DW_TAG_template_type_param to interpret a DW_TAG_structure_type as template instanciation. GCC and clang omit this in some cases though.
</td>
</tr>
<tr>
<th>Product</th>
<td>lldb
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>All Bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>lldb-dev@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Reporter</th>
<td>dkreuter@gmail.com
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>While debugging the following code
extern "C" long write(int fd, const void *buf, long count);
template <class _CharT> struct char_traits;
template <typename _CharT, typename _Traits = char_traits<_CharT>>
class basic_string {
const _CharT *data;
public:
basic_string (const _CharT *_data) : data(_data) {}
const _CharT& operator[] (int i) const {
return data[i];
}
};
int main (int argc, char **argv) {
basic_string<char> strvar("abcdef\n");
write(1, &strvar[0], 7);
return 0;
}
What happens:
(lldb) break set -l 19
Breakpoint 1: where = bin.clang`main + 89 at test.cpp:19, address = ...
(lldb) run
...
(lldb) expr strvar[3]
error: call to a function 'basic_string<char, char_traits<char>
<span class="quote">>::operator[](int) const' ('_ZNK12basic_stringIc17char_traits<char>EixEi') that</span >
is not present in the target
error: The expression could not be prepared to run in the target
What should happen:
(gdb) break 19
Breakpoint 1 at 0x4005f6: file test.cpp, line 19.
(gdb) run
...
(gdb) print strvar[3]
$1 = (const char &) @0x40071b: 100 'd'
LLDB tries to call
_ZNK12basic_stringIc17char_traits<char>EixEi
but should be calling
_ZNK12basic_stringIc11char_traitsIcEEixEi
In DWARF, basic_string<char, char_traits<char> > is represented as a hierarchy
of
DW_TAG_class_type (DW_AT_name: basic_string<char, char_traits<char> >)
DW_TAG_member
DW_TAG_subprogram
...
DW_TAG_subprogram
...
DW_TAG_template_type_parameter _CharT = char
DW_TAG_template_type_parameter _Traits = char_traits<char>
but char_traits<char> is represented as
DW_TAG_structure_type (DW_AT_name: char_traits<char>)
(lacking DW_TAG_template_type_parameter)
The only indication that there is a template parameter is the
presence of '<' in the name, and in fact this heuristic is used in LLDB at
SymbolFileDWARF.cpp:6198 if (type_name_cstr && strchr (type_name_cstr,
'<'))
ParseTemplateParameterInfos (called a few lines below this 'if') fails to
create a clang_type, and so a fallback based on CreateRecordType creates a type
that contains '<' in the name, for which symbols can not be found in the
binary. ("17char_traits<char>" vs "11char_traitsIc")
Fixing this probably involves extending ParseTemplateParameterInfos to work
when no DW_TAG_template_type_parameter is present.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>