[patch 0/2] physname reg.: C++ breakpoints / linespec fixes

[Jan Kratochvil <jan.kratochvil@redhat.com>]

Hi,

as discussed in the "The future of dwarf2_physname" thread GDB lost the
ability to fallback to minimal symbols (ELF .symtab & co.) from full symbols
(DWARF .debug_info etc.) in some cases, due to physname:
-         if (paren_pointer == NULL)
-           return decode_compound (argptr, funfirstline, canonical,
change into unconditional - approx.:
+           return decode_compound (argptr, funfirstline, canonical,

[patch 1/2]
One reason if there are some bugs and/or discrepancies between GCC, DWARF and
GDB regarding DWARF which is sometimes even missing DW_AT_linkage_name.
The minimal symbols are at least one way how to `break' at some function.

Another point is that sometimes the DWARF is missing, either for parts of the
app compiled without -g or for system libraries which do not have separate
debug info installed.

[patch 2/2]
Another problem is "Junk at end of arguments." for more complicated function
specifiers.  It is due to the physname patch part:
-  else if (paren_pointer != NULL)
-    {
-      p = paren_pointer + 1;
-    }
The idea here is instead of chasing which every string can still be a part of
the function specification (as being done by current physname code) one can
rather to stop on any string which looks as a linespec stopper.  It would be
a problem if it could be ambiguous but I haven't found any countercase, would
you?  That is:
 * it is worse to parse "operator()" and leave "(int)" there
   causing "Junk at end of arguments." 
instead of the failure case of the proposed code:
 * possibly consider whole "funcname threaf 1" (`threaf' is a `thread' typo)
   as a function name failing to look up symbol "funcname threaf 1".  It just
   leads to a different error type but it would end up by an error anyway.

I have not addressed specific PRs, I was addressing to have no regressions
against pre-physname GDB, that is to the FSF gdb-7.1 state, before:
	commit 42284fdf9d8cdb20c8e833bdbdb2b56977fea525
	Author: Keith Seitz <keiths@redhat.com>
	Date:   Tue Mar 9 18:09:04 2010 +0000
	    dwarf2_physname patchset:

as tested by my gdb-breakpoint*.pl scripts posted at:
	Re: [RFA] 12266 (typedef'd parameters) revisited again
	http://sourceware.org/ml/gdb-patches/2011-06/msg00067.html

that is to be able to at least:
	(gdb) break 'function name as seen in nm -C'

So far I have not tried to test regressions without quotes but (a) hopefully
it also works and (b) adding quotes should be users be used to as
a workaround, it is worse if one cannot figure out how to putsthe breakpoint.

I understand all the various bugs in decode_compound code (such as the one about `operator ()') and in physname
mangling etc. can be fixed but these two
patches try to address it in a generic way.  linespec is IMNSHO a hack anyway
and one day it should be merged with the general expression parser (used for
example for `print'); which should be further merged with GCC/G++ parser.
	Expression Parser Plug-In Available
	http://sourceware.org/ml/archer/2011-q1/msg00122.html

So the goal here is to get no regressions with gdb-breakpoint*.pl scripts,
I did not try to summarize all the regression types to create a GDB testcase
for each of them.  The new testcases are only illustrative for the specific
fixes FAIL->PASS, I was not trying to address each specific problems by this
patchset anyway.


Thanks,
Jan