This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, 07 Jun 2011 22:23:53 +0200, Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> 
> Jan> linespec is IMNSHO a hack anyway and one day it should be merged
> Jan> with the general expression parser (used for example for `print');
> Jan> which should be further merged with GCC/G++ parser.  Expression
> Jan> Parser Plug-In Available
> Jan> http://sourceware.org/ml/archer/2011-q1/msg00122.html
> 
> I am not sure this is the right direction.  I have a few issues with it.
> 
> First, it seems to me that we'll always have to keep some part of
> linespecs around, because 'break file:line' is important.  So, we'll
> always have to look at the argument in multiple ways and decide what to
> do.

The `line' case is sure not useful for expressions.  But for example
`file:func' is currently implemented only in linespec and it should be
supported even by expressions - see the bottom example.

The `file:line' could be implemented as a special expression as otherwise all
the parsing and escaping of the possibly whitespaced `file' part would have to
be implemented twice and we would get to the same pain.


> Second, I suspect this ties linespecs too closely to the current language.
> It seems reasonable to me for 'break ns::func()' to work in a C frame.

C++ is generally backward compatible with C, I do not find some problems with
fallback to this or that language if the other language parsing gave an error.

For the special cases of some valid parsing in both languages but ambiguous
due to some overloaded C++ operators one can require proper `set language' to
be set.  One can face it only in some heavily overloaded projects (like
Mozilla IIRC) and the developers would be aware of it.


> Third, IIRC your branch is based on the idea of the parser constructing
> an expression, which is then decoded (or evalled?) to find the correct
> symbol.  I think this approach neglects the possibility that a linespec
> could be ambiguous, another hot topic.

Debugger could handle some way even possibly-ambigous expressions.
`print funcname' depends on context and the debugger user is IMO not so
strictly aware of the current context like the programmer is.


Thanks,
Jan


==> a/f.c <==
static void f (void) {}
void x (void) { f (); }

==> b/f.c <==
static void f (void) {}
void y (void) { f (); }

==> m.c <==
extern void x (void);
extern void y (void);
int
main (void)
{
  x ();
  y ();
  return 0;
}

gcc -o m a/f.c b/f.c m.c -Wall -g 
(gdb) b a/f.c:f
Breakpoint 1 at 0x400478: file a/f.c, line 1.
(gdb) b b/f.c:f
Breakpoint 2 at 0x40048c: file b/f.c, line 1.
(gdb) b f
Note: breakpoint 2 also set at pc 0x40048c.
Breakpoint 3 at 0x40048c: file b/f.c, line 1.
(gdb) p f
$1 = {void (void)} 0x400488 <f>
(gdb) p a/f.c:f
No symbol "a" in current context.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = it should work.
(gdb) p b/f.c:f
No symbol "b" in current context.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = it should work.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]