Problem debugging C++ (egcs-1.1b) with gdb-4.17/gdb-4.16 on DecUnix-4.0[a-d]

Mike Stump mrs@wrs.com
Mon Dec 7 20:30:00 GMT 1998


> Date: Fri, 04 Dec 1998 15:00:09 +0100
> From: Aurel Balmosan <ab@orga.com>
> To: egcs-bugs <egcs-bugs@cygnus.com>

> (gdb) n
> CpFmtLine::Set (this=0x20, l=0x14001c8a0 "°êÿ\037\001") at CpTool.cc:274
> 274     {       int sz, pos;
> (gdb) n
> 0x12006c158 in __get_eh_context ()
> Current language:  auto; currently c
> (gdb) n
> Single stepping until exit from function __get_eh_context,
> which has no line number information.
> error in position:11 str-part:[   ]              <--------- This is output from
> my program.

> As you see the parameter list of the method Set contains invalid
> data then the __get_eh_context() is executed and then a next command
> leads to a continue until another breakpoint is hit or the program
> terminates. Also you notice that I used 'next' and not step but the
> debugger steps into the method 'Set'. Im very sure that this is not
> a debugger problem because the same program compiled with
> gcc-2.7.2.3 don't show the problem while debugging. Maybe the
> parameter passing has changed in egcs-1.* on DEC-Unix which does not
> follow the standard defined by Digital and expected by the gdb
> debuggers.

I wonder if inlining is causing slightly confusing to you output, if
so this isn't a bug.

Anyway, the real bug, I wonder if it is the same one I am seeing, if
it is, this:

Doing diffs in function.c.~1~:
*** function.c.~1~	Fri Nov 20 13:49:27 1998
--- function.c	Mon Dec  7 20:23:44 1998
*************** assign_parms (fndecl, second_time)
*** 4646,4651 ****
--- 4646,4654 ----
       now that all parameters have been copied out of hard registers.  */
    emit_insns (conversion_insns);
  
+   if (flag_exceptions)
+     emit_line_note_force (input_filename, lineno);
+ 
    last_parm_insn = get_last_insn ();
  
    current_function_args_size = stack_args_size.constant;
--------------

will fix it.  This is a hack workaround and not a fix.  The proper fix
I think belongs in gdb.  The problem is that gdb sets a temporary
breakpoint and computes the value of fp so that it can distinguish
recursive calls, but it gets the value wrong and hence it never stops
at that breakpoint.

This patch makes it work by allowing gdb to notice that it left the
linenumber region in memory, then it recomputes fp, and then the
continues stepping and then it works.

gdb doesn't handle the call without the stab, as it thinks the call is
part of the prologue for the function.

Maybe someone on the gdb team can confirm/fix, if they really want the
extra stab, then it's back to the egcs folks to decide.

Happens on at least 386, ppc and 68k targets, but I suspect many more
than that.

I was using a description of the problem and a description of a
solution (dup stabs entry) and the following code:

struct A { A() { } ~A() { } } ;
main() 
{
A a;
}



More information about the Gdb mailing list