This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[patch 0/2] physname reg.: C++ breakpoints / linespec fixes
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: gdb-patches at sourceware dot org
- Date: Sun, 5 Jun 2011 22:26:15 +0200
- Subject: [patch 0/2] physname reg.: C++ breakpoints / linespec fixes
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