Re: gdb 8.x - g++ 7.x compatibility

[Roman Popov <ripopov@gmail.com>]

I've just checked g++8.0.1 from trunk, and the problem is still there. And
same with Clang compiler.

This is indeed is a serious issue for me, since my Python scripts for gdb
expect reliable dynamic type identification. However gdb is
completely powerless here. So I'm forced to stay on older compiler.
Consider this case (Results with g++ 8.0.1)

#include <iostream>
struct base {
    virtual void print() = 0;
};

template< auto IVAL>
struct foo : base {
    decltype(IVAL) x = -IVAL;
    void print() override { std::cout << x << std::endl; };
};

int main()
{
    base * fu = new foo<10u>();
    base * fi = new foo<10>();
    fu->print();
    fi->print();
    return 0;     // set breakpoint here
}:

Now check dynamic types in GDB:

(gdb) p *fu
warning: RTTI symbol not found for class 'foo<10u>'
$1 = warning: RTTI symbol not found for class 'foo<10u>'
warning: RTTI symbol not found for class 'foo<10u>'
{_vptr.base = 0x400bd0 <vtable for foo<10u>+16>}

(gdb) p *fi

(gdb) p *fi
$2 = (foo<10>) {<base> = {_vptr.base = 0x400bb8 <vtable for foo<10>+16>}, *x
= 4294967286*}

Here GDB picks wrong type!

In RTTI type names are different. And this is correct.

But in debuginfo both types have same name:

foo<10> {
  unsigned x;
}
foo<10> {
  int x;
}

So GDB picks the first one, which is wrong.

-Roman








2018-02-03 6:20 GMT-08:00 Paul Smith <psmith@gnu.org>:

> On Fri, 2018-02-02 at 23:54 -0500, Simon Marchi wrote:
> > Your problem is probably linked to these issues, if you want to follow
> > them:
> >
> > gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932
> > gdb: https://sourceware.org/bugzilla/show_bug.cgi?id=22013
> >
> > As Carl said, it's a good idea to try with the latest version of both
> > tools, but I think the issue will still be present.
> >
> > GCC changed how it outputs unsigned template parameters in the debug
> > info (from 2u to just 2), and it doesn't look like it's going to change
> > it back.  So I suppose we'll have to find a way to make GDB deal with
> > it.
>
> I also tried a couple of times [1][2][3] to get a discussion started on
> the mailing lists for how to resolve this but didn't get any replies,
> and I got busy with other things.
>
> We really need to find someone who is knowlegeable on type lookup in
> GDB.  That person needs to engage with the experts on the GCC side and
> hash out the right answer to this problem.  In my experience, Jonathan
> Wakely on the GCC side is extremely responsive, I'm just too much of a
> tyro to be able to discuss it with him at the level needed to find a
> solution.
>
> I think it's an extremely serious issue, if GDB can't resolve some very
> common (IME) types, but so far it hasn't risen to the level of getting
> attention from those who have sufficient expertise to solve it.
>
>
> [1] https://gcc.gnu.org/ml/gcc-help/2017-08/msg00120.html
> [2] https://sourceware.org/ml/gdb/2017-08/msg00069.html
> [3] https://sourceware.org/ml/gdb/2017-09/msg00042.html
>