gdb.cp/templates.exp, ctor/dtor breakpoints, etc....

gdb.cp/templates.exp, ctor/dtor breakpoints, etc....

[Christophe LYON]

Hello,

While trying to improve my Open64/Gcc-3-3-3 based compiler results on 
the gdb-6.8 testsuite, I noticed on gdb.cp/templates.exp that even on 
x86/GCC-4.1.x there are still several KFAIL tests dating back to 2003.

In particular, there are issues when setting breakpoints on ctor/dtor.

I thought that the recent support for multiple breakpoints would fix 
this, so I am a bit surprised.

Could someone give me some updated status in this area: should the tests 
be revisited, or is it GDB itself that should be fixed, or GCC?

Thanks,

Christophe.

Re: gdb.cp/templates.exp, ctor/dtor breakpoints, etc....

[Daniel Jacobowitz]

On Fri, Jan 16, 2009 at 11:19:46AM +0100, Christophe LYON wrote:
> Hello,
>
> While trying to improve my Open64/Gcc-3-3-3 based compiler results on the 
> gdb-6.8 testsuite, I noticed on gdb.cp/templates.exp that even on  
> x86/GCC-4.1.x there are still several KFAIL tests dating back to 2003.
>
> In particular, there are issues when setting breakpoints on ctor/dtor.
>
> I thought that the recent support for multiple breakpoints would fix  
> this, so I am a bit surprised.

They've all got PRs associated with them that explain the problems.
Most of them seem to deal with menus or with the names of the
constructors/destructors; we've mostly fixed breakpoints by line
number.

> Could someone give me some updated status in this area: should the tests  
> be revisited, or is it GDB itself that should be fixed, or GCC?

In general we use kfail only for GDB bugs, not GCC bugs.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb.cp/templates.exp, ctor/dtor breakpoints, etc....

[Christophe LYON]

On 16.01.2009 16:03, Daniel Jacobowitz wrote:
> On Fri, Jan 16, 2009 at 11:19:46AM +0100, Christophe LYON wrote:
>> Hello,
>>
>> While trying to improve my Open64/Gcc-3-3-3 based compiler results on the 
>> gdb-6.8 testsuite, I noticed on gdb.cp/templates.exp that even on  
>> x86/GCC-4.1.x there are still several KFAIL tests dating back to 2003.
>>
>> In particular, there are issues when setting breakpoints on ctor/dtor.
>>
>> I thought that the recent support for multiple breakpoints would fix  
>> this, so I am a bit surprised.
> 
> They've all got PRs associated with them that explain the problems.
> Most of them seem to deal with menus or with the names of the
> constructors/destructors; we've mostly fixed breakpoints by line
> number.
> 
>> Could someone give me some updated status in this area: should the tests  
>> be revisited, or is it GDB itself that should be fixed, or GCC?
> 
> In general we use kfail only for GDB bugs, not GCC bugs.
> 
If I take the example of PR 1112 (now bugzilla #8217), which is an issue 
with destructor breakpoints, the corresponding test in templates.exp 
used to pass with my compiler, until I stopped emitting the 
DW_AT_MIPS_linkage_name attribute.

Doing this, I follow GCC behaviour, but I get a regression. If we don't 
consider this a GCC bug, it means that the way GDB recognizes ctor/dtor 
(any probably any overloaded function) is to be revisited? Am I right?

Note that I am not asking for someone to do the job, I may have a look 
at it myself; I just want to make sure it is the right approach.


Christophe.

Re: gdb.cp/templates.exp, ctor/dtor breakpoints, etc....

[Daniel Jacobowitz]

On Fri, Jan 16, 2009 at 06:11:08PM +0100, Christophe LYON wrote:
> Doing this, I follow GCC behaviour, but I get a regression. If we don't  
> consider this a GCC bug, it means that the way GDB recognizes ctor/dtor  
> (any probably any overloaded function) is to be revisited? Am I right?

Yes, all of the name recognition stuff is broken.  We shouldn't be
relying on mangled names, since there are compilers we can not change
as easily as GCC or yours that do not emit them.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb.cp/templates.exp, ctor/dtor breakpoints, etc....

[Christophe LYON]

On 16.01.2009 18:18, Daniel Jacobowitz wrote:
> On Fri, Jan 16, 2009 at 06:11:08PM +0100, Christophe LYON wrote:
>> Doing this, I follow GCC behaviour, but I get a regression. If we don't  
>> consider this a GCC bug, it means that the way GDB recognizes ctor/dtor  
>> (any probably any overloaded function) is to be revisited? Am I right?
> 
> Yes, all of the name recognition stuff is broken.  We shouldn't be
> relying on mangled names, since there are compilers we can not change
> as easily as GCC or yours that do not emit them.
> 

Well, currently the gdb.cp/templates.exp is still KFAIL, so I guess the 
decision was that GCC should not output mangled names (somewhat 
confirmed by
http://gcc.gnu.org/ml/gcc/2001-12/msg00260.html).

But... if GDB does not rely on mangled names, how is it supposed to find 
the right template instantiation when trying to set a breakpoint on a 
function? For instance in templates.exp, where the T5 template is 
defined, how to find the T5<int> ctor, if all the ctor instantiations 
are named "T5" ? Should GDB analyse all the type definition in 
.debug_info and find the right type?

Christophe.

Re: gdb.cp/templates.exp, ctor/dtor breakpoints, etc....

[Daniel Jacobowitz]

On Mon, Jan 19, 2009 at 04:30:31PM +0100, Christophe LYON wrote:
> But... if GDB does not rely on mangled names, how is it supposed to find  
> the right template instantiation when trying to set a breakpoint on a  
> function? For instance in templates.exp, where the T5 template is  
> defined, how to find the T5<int> ctor, if all the ctor instantiations are 
> named "T5" ? Should GDB analyse all the type definition in .debug_info and 
> find the right type?

They're all named T5<X>::T5 for some X.  We get fully qualified type
names in the debug info.  The function should be contained in or
specified by the containing type.

Admittedly, for some template cases this gets really out of hand.
It's *hard* to represent Template<Type::Bar, 5, &(static_var)> as the
name of a type in DWARF.  But this can all be done using DW_AT_name;
it only gets really tricky if the compiler uses the DWARF extensions
for type and value parameters.

-- 
Daniel Jacobowitz
CodeSourcery