| Summary: | looking up structure members as symtabs? | ||
|---|---|---|---|
| Product: | gdb | Reporter: | dje |
| Component: | symtab | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | eclig, gdb-prs, richard_sharman, sam, ssbssa, tromey |
| Priority: | P2 | ||
| Version: | unknown | ||
| Target Milestone: | 8.2 | ||
| Host: | amd64-linux | Target: | |
| Build: | Last reconfirmed: | ||
I think this is a consequence of trying to classify names in the lexer, but without feedback from the parser. It'd be better for the C++ parser to follow Rust and drop yacc in favor of recursive descent. Then the parser is just ordinary code and the lexer can be made a bit less tricky -- like it can just return "this is a name" instead of trying to figure out the meaning of the name. Was fixed by this commit: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=59498c305e6f1db2a1ed8d44cb58f0d24ec092fe *** Bug 17772 has been marked as a duplicate of this bug. *** |
When parsing "p mybar.foo" gdb will do a global lookup of symbol "foo". That seems a tad clumsy. The bug, though, is that gdb may also try to lookup "foo" as a symtab. play$ cat foo /* Copy this to file "foo" and compile as gcc -g -x c foo -o foo.x */ struct bar { int foo; }; struct bar mybar; int main () { return 0; } play$ gcc -g -x c foo -o foo.x play$ build/obj64/gdb/gdb foo.x GNU gdb (GDB) 7.2.50.20100817-cvs [...] Reading symbols from /home/dje/src/play/foo.x...done. (gdb) start Temporary breakpoint 1 at 0x40044c: file foo, line 15. Starting program: /home/dje/src/play/foo.x Temporary breakpoint 1, main () at foo:15 15 return 0; (gdb) p mybar.foo A syntax error in expression, near `foo'. (gdb)