Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* multiple location in C++ constructors
@ 2008-10-14 15:13 Denis PILAT
  2008-10-16 13:51 ` Vladimir Prus
  0 siblings, 1 reply; 2+ messages in thread
From: Denis PILAT @ 2008-10-14 15:13 UTC (permalink / raw)
  To: gdb

We (at ST) have a compiler that generates DW_AT_MIPS_linkage_name 
attributes for constructors.
Unfortunately, that prevents breakpoint in constructor to have multiple 
locations since the gdb heuristics eliminates one location in the 
expand_line_sal_maybe() function of breakpoint.c: see bellow, we go thru 
the remove_sal () line.

(from breakpoint.c)
struct symtabs_and_lines
expand_line_sal_maybe (struct symtab_and_line sal)
...
	  if (find_pc_partial_function (pc, &this_function, 
					&func_addr, &func_end))
	    {
	      if (this_function && 
		  strcmp (this_function, original_function) != 0)
		{
		  remove_sal (&expanded, i);
		  --i;
		}
	      else if (func_addr == pc)	    
...



If present into dwarf2 debug information, the find_pc_partial_function() 
returns the DW_AT_MIPS_linkage_name in this_function, which is alway 
different from the original_function. Therefore there is always only one 
location for constructor breakpoints since the DW_AT_MIPS_linkage_name 
is filled with the mangled function name.


My question is:
Is the GDB heuristic to find multiple location for breakpoint wrong ?
Or is the DW_AT_MIPS_linkage_name attribute for constructors useless in 
debug informations ?

Thanks for your feedback
Denis


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: multiple location in C++ constructors
  2008-10-14 15:13 multiple location in C++ constructors Denis PILAT
@ 2008-10-16 13:51 ` Vladimir Prus
  0 siblings, 0 replies; 2+ messages in thread
From: Vladimir Prus @ 2008-10-16 13:51 UTC (permalink / raw)
  To: gdb

Denis PILAT wrote:

> We (at ST) have a compiler that generates DW_AT_MIPS_linkage_name
> attributes for constructors.
> Unfortunately, that prevents breakpoint in constructor to have multiple
> locations since the gdb heuristics eliminates one location in the
> expand_line_sal_maybe() function of breakpoint.c: see bellow, we go thru
> the remove_sal () line.
> 
> (from breakpoint.c)
> struct symtabs_and_lines
> expand_line_sal_maybe (struct symtab_and_line sal)
> ...
> if (find_pc_partial_function (pc, &this_function,
> &func_addr, &func_end))
> {
> if (this_function &&
> strcmp (this_function, original_function) != 0)
> {
> remove_sal (&expanded, i);
> --i;
> }
> else if (func_addr == pc)
> ...
> 
> 
> 
> If present into dwarf2 debug information, the find_pc_partial_function()
> returns the DW_AT_MIPS_linkage_name in this_function, which is alway
> different from the original_function. Therefore there is always only one
> location for constructor breakpoints since the DW_AT_MIPS_linkage_name
> is filled with the mangled function name.
> 
> 
> My question is:
> Is the GDB heuristic to find multiple location for breakpoint wrong ?

An heuristic, by definition, is sometimes wrong. 

> Or is the DW_AT_MIPS_linkage_name attribute for constructors useless in
> debug informations ?

I don't really know the answer to this question, but I think the right answer
is to make sure that all ways GDB has to search a function for PC should
return the same name. And probably, breakpoint setting code should resolve
back from PC to name, so that if you put breakpoint on 

        C::C

where C is a class in some namespace, the 'info break' will report:

        some_namespace::C::C

and find_partial_function will report same, and comparison will yield true.
Alternatively, somebody should come up with a better way to tell if PC1
and PC2 belong to instantination of a template function with different
parameters.

- Volodya



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2008-10-16 13:51 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-10-14 15:13 multiple location in C++ constructors Denis PILAT
2008-10-16 13:51 ` Vladimir Prus

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox