[lldb-dev] [Bug 20455] 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.

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=20455

            Bug ID: 20455
           Summary: 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.
           Product: lldb
           Version: unspecified
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: lldb-dev at cs.uiuc.edu
          Reporter: dkreuter at gmail.com
    Classification: Unclassified

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>
>::operator[](int) const' ('_ZNK12basic_stringIc17char_traits<char>EixEi') that
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140726/ba0f93a1/attachment.html>