Bug 15631 – gdb: Parent's scope not considered for symbol lookup

Tested with 'GNU gdb (GDB) 7.10.1' (latest release) + DMD 2.069-but-really-2.070. Using the following code: ``` class Base { int value; } class Derivative : Base { int derived_value; void foo () { assert(value == 0); assert(derived_value == 0); } } void main () { auto d = new Derivative(); d.foo; } ``` and compiling with DMD: ``` Breakpoint 1, gdb_scope.Derivative.foo() (this=0x7ffff7ec3000) at gdb_scope.d:5 5 void foo () { assert(value == 0); assert(derived_value == 0); } (gdb) p value No symbol "value" in current context. (gdb) p *this $1 = {derived_value = 0} ``` This issue makes it quite complex to trace DMD using gdb, unless DMD is compiled with GDC.

:-D

*** Issue 20839 has been marked as a duplicate of this issue. ***

Marking as duplicate of 20839 Because 20839 has more actionable information *** This issue has been marked as a duplicate of issue 20839 ***

No it does not. It has a vague description, and no test case. The description focuses on what's in the debug info rather than the actual issue(s). If you want to add informations about why we're seeing this, add a comment here, but I'd rather we do not close issues with test case for the benefit of one without. For reference, the information added is: > the child class `Child` does not have a member `x` according to debuginfo > This is because a `DW_TAG_inheritance` is missing. In this issue, `Derivative` was used instead of `Child`, and `value` instead of `x`.

*** Issue 20839 has been marked as a duplicate of this issue. ***

Ran into similar problem with delegates: ------------- void fun(void delegate() dg) { dg(); } void main() { int x = 123; string y = "abc"; fun({ x++; y ~= "d"; }); } ------------- Compiled with `dmd -g prog.d`. In gdb: ------------ (gdb) break prog.main Breakpoint 1 at 0x43734: file prog.d, line 8. (gdb) run Starting program: /tmp/prog [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, prog.main().__lambda3() (__capture=0x7ffff7cad000) at prog.d:8 8 x++; (gdb) p x No symbol "x" in current context. (gdb) p y No symbol "y" in current context. (gdb) p __capture.x $1 = 123 (gdb) p __capture.y $2 = "abc" ------------ Apparently `__capture` must be entered explicitly in order to access closed-over variables. It would be nice to have symbol lookup automatically look in __capture.

A simpler example with module globals: -------- import std; int x = 12345; void main() { writeln(x); } -------- Compile with `dmd -g prog.d`. In gdb: -------- (gdb) break D main Breakpoint 1 at 0xe1b9c: file prog.d, line 4. (gdb) run Starting program: /tmp/prog [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, D main () at prog.d:4 4 writeln(x); (gdb) p x No symbol "x" in current context. -------- Expected behaviour: the module global `x` should be known to the debugger and inspectable from the debugger.

P.S. it appears that the FQN `prog.x` is required for accessing the module global: ---------- (gdb) p prog.x $1 = 12345 ---------- It would be nice if this were automated based on the current context.

(In reply to hsteoh from comment #8) > P.S. it appears that the FQN `prog.x` is required for accessing the module > global: > > ---------- > (gdb) p prog.x > $1 = 12345 > ---------- > > It would be nice if this were automated based on the current context. Support code is there, however the compiler must emit 'D main' as being a child of the module.

(In reply to hsteoh from comment #6) > Ran into similar problem with delegates: > > Apparently `__capture` must be entered explicitly in order to access > closed-over variables. It would be nice to have symbol lookup automatically > look in __capture. This used to work when the parameter was named 'this'. However since the adhoc rename, gdb needs to be taught where to look for the context pointer now.

By the way @hsteoh, what you describe are two *different* issues to this one, and should be raised independently. This issue is for derived classes not having all base members/methods emitted in debug.

@UplinkCoder updated dlang/dmd pull request #12925 "Prepend baseclass fields to symbol for debugging" fixing this issue: - Prepend baseclass fields to symbol for debugging Fix Issue 15631 https://github.com/dlang/dmd/pull/12925

@rainers updated dlang/dmd pull request #12978 "fix issue 15631 - gdb: Parent's scope not considered for symbol lookup" fixing this issue: - fix issue 15631 - gdb: Parent's scope not considered for symbol lookup add basic inheritance information to class type https://github.com/dlang/dmd/pull/12978

dlang/dmd pull request #12978 "fix issue 15631 - gdb: Parent's scope not considered for symbol lookup" was merged into master: - 974b8523206f70116dd99d1d75cff051baa93fcf by Rainer Schuetze: fix issue 15631 - gdb: Parent's scope not considered for symbol lookup add basic inheritance information to class type https://github.com/dlang/dmd/pull/12978