Re: [6.2] PROBLEMS file

Re: [6.2] PROBLEMS file

[Michael Elizabeth Chastain]

joel> FWIW: As a user, I don't mind when the unwinder goes too far and
joel> displays too many frames.  The info we're looking for is there, and
joel> that's what really counts for me. Not pretty, but good enough.
joel> So I wouldn't mind closing that particular PR, especially since
joel> there doesn't seem to be any accurate way of detecting the top
joel> of the call stack.

There are really two separate problems here.  gdb/1505 is all about
top-of-stack detection.  How about we document the limitation and
live with it.

The existing text is:

  Most programs have a standard user entry point---a place where system
  libraries and startup code transition into user code.  For C this is
  @code{main}.  When @value{GDBN} finds the entry function in a
  backtrace it will terminate the backtrace, to avoid tracing into highly
  system-specific (and generally uninteresting) code.

How about adding something like this:

  @value{GDBN} is not perfect at detecting the top of the call stack.
  For instance, if your program creates multiple threads, then the
  stack of an individual thread may not start with @code{main} at all.
  So you may see strange frames at the top of the stack; it is safe to
  ignore these.

If we document it, I am okay with closing the PR.

(And while I was reading the doco I noticed "set backtrace limit" is
already implemented, which is exactly what I want for callfuncs.exp!)

The other problem is strange frames in the middle that cause the
trace to go bad before it gets to any interesting user code.
That's a different, and much worse, problem, but it's not PR gdb/1505.
See PR gdb/1255 and PR gdb/1253.  Those two particular PR's have been
fixed.

Michael C

Re: [6.2] PROBLEMS file

[Andrew Cagney]

> joel> FWIW: As a user, I don't mind when the unwinder goes too far and
> joel> displays too many frames.  The info we're looking for is there, and
> joel> that's what really counts for me. Not pretty, but good enough.
> joel> So I wouldn't mind closing that particular PR, especially since
> joel> there doesn't seem to be any accurate way of detecting the top
> joel> of the call stack.
> 
> There are really two separate problems here.  gdb/1505 is all about
> top-of-stack detection.  How about we document the limitation and
> live with it.

We fix it.

Andrew

Re: [6.2] PROBLEMS file

[Eli Zaretskii]

> Date: Fri, 23 Jul 2004 14:16:14 +0200 (CEST)
> From: Mark Kettenis <kettenis@chello.nl>
> 
> I've filed a bug report and I'm working on it.

Thanks.

It was a shock for me to see GDB produce bogus backtraces.  I thought:
"How can I trust a debugger that cannot even give me a fair
backtrace?"

Re: [6.2] PROBLEMS file

[Mark Kettenis]

   Date: Fri, 23 Jul 2004 14:16:37 +0200
   From: "Eli Zaretskii" <eliz@gnu.org>

   > Date: Fri, 23 Jul 2004 11:23:32 +0200 (CEST)
   > From: Mark Kettenis <kettenis@chello.nl>
   > 
   > GDB loses track after frame #21, but I doubt whether
   > recursive_edit_1 is a frameless function.  Can you post a
   > dissassembly of that function?

   Here it is:

   (gdb) disassemble recursive_edit_1
   Dump of assembler code for function recursive_edit_1:
   0x0005f7b0 <recursive_edit_1+0>:	push   %ebp
   0x0005f7b1 <recursive_edit_1+1>:	mov    0x375aa0,%eax
   0x0005f7b6 <recursive_edit_1+6>:	mov    %esp,%ebp

Aha.  This `mov 0x375aa0,%eax' has crept inbetween the `push %bp' and
`mov %esp,%ebp'.  The prologue analyzer doesn't deal with it, but this
should be easy to fix.  I've filed a bug report and I'm working on it.

Mark

RE: [6.2] PROBLEMS file

[Dave Korn]

> -----Original Message-----
> From: gdb-owner On Behalf Of Eli Zaretskii
> Sent: 23 July 2004 13:17
> To: Mark Kettenis

> > Date: Fri, 23 Jul 2004 11:23:32 +0200 (CEST)
> > From: Mark Kettenis 
> > 
> > GDB loses track after frame #21, but I doubt whether
> > recursive_edit_1 is a frameless function.  Can you post a
> > dissassembly of that function?
> 
> Here it is:
> 
> (gdb) disassemble recursive_edit_1
> Dump of assembler code for function recursive_edit_1:
> 0x0005f7b0 <recursive_edit_1+0>:	push   %ebp
> 0x0005f7b1 <recursive_edit_1+1>:	mov    0x375aa0,%eax
> 0x0005f7b6 <recursive_edit_1+6>:	mov    %esp,%ebp

<SPECULATIVE strength=plausible>

  Somebody's implemented schedulable rtl prolog insn patterns in i386 gcc
and now the gdb prolog analysis gives up when it finds an instruction it
doesn't recognise has been moved backward by the scheduler from the function
body to in amongst the prolog instructions.

  I believe this may also explain the thread "GDB seems to set breakpoints
on functions at the wrong place" at 
http://sources.redhat.com/ml/gdb/2004-07/msg00107.html, so I've Cc'd the OP
of that message back in here.

  Hmm.  I found this interesting comment in i386.md:

;; Prologue and epilogue instructions

;; UNSPEC_VOLATILE is considered to use and clobber all hard registers and
;; all of memory.  This blocks insns from being moved across this point.

  Perhaps someone has removed one that previously used to be emitted to keep
body insns out of the prolog.

</SPECULATIVE>


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: [6.2] PROBLEMS file

[Eli Zaretskii]

> Date: Fri, 23 Jul 2004 14:16:37 +0200
> From: "Eli Zaretskii" <eliz@gnu.org>
> 
> > Date: Fri, 23 Jul 2004 11:23:32 +0200 (CEST)
> > From: Mark Kettenis <kettenis@chello.nl>
> > 
> > GDB loses track after frame #21, but I doubt whether
> > recursive_edit_1 is a frameless function.  Can you post a
> > dissassembly of that function?
> 
> Here it is:

Sorry, I failed to mention my GCC version.  It's 3.3.3.  I could
install 3.4.1 and try with that, if it matters.

Re: [6.2] PROBLEMS file

[Eli Zaretskii]

> Date: Fri, 23 Jul 2004 11:23:32 +0200 (CEST)
> From: Mark Kettenis <kettenis@chello.nl>
> 
> GDB loses track after frame #21, but I doubt whether
> recursive_edit_1 is a frameless function.  Can you post a
> dissassembly of that function?

Here it is:

(gdb) disassemble recursive_edit_1
Dump of assembler code for function recursive_edit_1:
0x0005f7b0 <recursive_edit_1+0>:	push   %ebp
0x0005f7b1 <recursive_edit_1+1>:	mov    0x375aa0,%eax
0x0005f7b6 <recursive_edit_1+6>:	mov    %esp,%ebp
0x0005f7b8 <recursive_edit_1+8>:	push   %esi
0x0005f7b9 <recursive_edit_1+9>:	mov    0x375950,%esi
0x0005f7bf <recursive_edit_1+15>:	push   %ebx
0x0005f7c0 <recursive_edit_1+16>:	sub    %eax,%esi
0x0005f7c2 <recursive_edit_1+18>:	mov    0x36d2a0,%eax
0x0005f7c7 <recursive_edit_1+23>:	sar    $0x4,%esi
0x0005f7ca <recursive_edit_1+26>:	test   %eax,%eax
0x0005f7cc <recursive_edit_1+28>:	jle    0x5f7fa <recursive_edit_1+74>
0x0005f7ce <recursive_edit_1+30>:	mov    0x3753b0,%ebx
0x0005f7d4 <recursive_edit_1+36>:	mov    0x375e50,%ecx
0x0005f7da <recursive_edit_1+42>:	push   %eax
0x0005f7db <recursive_edit_1+43>:	push   %eax
0x0005f7dc <recursive_edit_1+44>:	push   %ebx
0x0005f7dd <recursive_edit_1+45>:	push   %ecx
0x0005f7de <recursive_edit_1+46>:	call   0xc73b0 <specbind>
0x0005f7e3 <recursive_edit_1+51>:	pop    %eax
0x0005f7e4 <recursive_edit_1+52>:	mov    0x376450,%ebx
0x0005f7ea <recursive_edit_1+58>:	pop    %edx
0x0005f7eb <recursive_edit_1+59>:	mov    0x3753b0,%eax
0x0005f7f0 <recursive_edit_1+64>:	push   %eax
0x0005f7f1 <recursive_edit_1+65>:	push   %ebx
0x0005f7f2 <recursive_edit_1+66>:	call   0xc73b0 <specbind>
0x0005f7f7 <recursive_edit_1+71>:	add    $0x10,%esp
0x0005f7fa <recursive_edit_1+74>:	mov    0x3753e0,%edx
0x0005f800 <recursive_edit_1+80>:	mov    0x369290,%eax
0x0005f805 <recursive_edit_1+85>:	push   %ecx
0x0005f806 <recursive_edit_1+86>:	push   %ecx
0x0005f807 <recursive_edit_1+87>:	push   %edx
0x0005f808 <recursive_edit_1+88>:	push   %eax
0x0005f809 <recursive_edit_1+89>:	call   0xc73b0 <specbind>
0x0005f80e <recursive_edit_1+94>:	movl   $0x0,0x369570
0x0005f818 <recursive_edit_1+104>:	call   0x5fca0 <command_loop>
0x0005f81d <recursive_edit_1+109>:	add    $0x10,%esp
0x0005f820 <recursive_edit_1+112>:	mov    %eax,%ebx
0x0005f822 <recursive_edit_1+114>:	cmp    0x3753b0,%eax
0x0005f828 <recursive_edit_1+120>:	je     0x5f871 <recursive_edit_1+193>
0x0005f82a <recursive_edit_1+122>:	mov    %ebx,%eax
0x0005f82c <recursive_edit_1+124>:	and    $0x7,%eax
0x0005f82f <recursive_edit_1+127>:	cmp    $0x3,%eax
0x0005f832 <recursive_edit_1+130>:	je     0x5f850 <recursive_edit_1+160>
0x0005f834 <recursive_edit_1+132>:	mov    0x3753e0,%ebx
0x0005f83a <recursive_edit_1+138>:	push   %eax
0x0005f83b <recursive_edit_1+139>:	push   %eax
0x0005f83c <recursive_edit_1+140>:	push   %ebx
0x0005f83d <recursive_edit_1+141>:	push   %esi
0x0005f83e <recursive_edit_1+142>:	call   0xc7650 <unbind_to>
0x0005f843 <recursive_edit_1+147>:	lea    0xfffffff8(%ebp),%esp
0x0005f846 <recursive_edit_1+150>:	pop    %ebx
0x0005f847 <recursive_edit_1+151>:	pop    %esi
0x0005f848 <recursive_edit_1+152>:	pop    %ebp
0x0005f849 <recursive_edit_1+153>:	ret    
0x0005f84a <recursive_edit_1+154>:	lea    0x0(%esi),%esi
0x0005f850 <recursive_edit_1+160>:	push   %eax
0x0005f851 <recursive_edit_1+161>:	push   %eax
0x0005f852 <recursive_edit_1+162>:	mov    0x3753e0,%eax
0x0005f857 <recursive_edit_1+167>:	push   %eax
0x0005f858 <recursive_edit_1+168>:	push   %ebx
0x0005f859 <recursive_edit_1+169>:	call   0xae430 <Fcons>
0x0005f85e <recursive_edit_1+174>:	pop    %edx
0x0005f85f <recursive_edit_1+175>:	pop    %ecx
0x0005f860 <recursive_edit_1+176>:	push   %eax
0x0005f861 <recursive_edit_1+177>:	mov    0x3754f0,%eax
0x0005f866 <recursive_edit_1+182>:	push   %eax
0x0005f867 <recursive_edit_1+183>:	call   0xc5140 <Fsignal>
0x0005f86c <recursive_edit_1+188>:	add    $0x10,%esp
0x0005f86f <recursive_edit_1+191>:	jmp    0x5f834 <recursive_edit_1+132>
0x0005f871 <recursive_edit_1+193>:	push   %eax
0x0005f872 <recursive_edit_1+194>:	push   %eax
0x0005f873 <recursive_edit_1+195>:	mov    0x3753e0,%eax
0x0005f878 <recursive_edit_1+200>:	push   %eax
0x0005f879 <recursive_edit_1+201>:	mov    0x375480,%eax
0x0005f87e <recursive_edit_1+206>:	push   %eax
0x0005f87f <recursive_edit_1+207>:	call   0xc5140 <Fsignal>
0x0005f884 <recursive_edit_1+212>:	add    $0x10,%esp
0x0005f887 <recursive_edit_1+215>:	jmp    0x5f82a <recursive_edit_1+122>
0x0005f889 <recursive_edit_1+217>:	lea    0x0(%esi),%esi
End of assembler dump.
(gdb) q

Re: [6.2] PROBLEMS file

[Mark Kettenis]

   Date: Fri, 23 Jul 2004 11:09:25 +0200
   From: "Eli Zaretskii" <eliz@gnu.org>

   I did.  It's possible that I misunderstand something, or even make
   some stupid mistake, but there's no need to assume I didn't read the
   message to which I responded.

Sorry Eli.  I lost my temper a bit.  The issue keeps coming up again
and again :-(.

   > Frame #2 is executing Microsoft shit.  I
   > don't know what debugging format they use, and I don't think they ship
   > their official releases with debugging info in it.

   Sorry, I fail to see the relevance of this.  No matter what debug info
   is there, GDB should be able to track stack frames, shouldn't it?  And
   it actually does at least once: it succeeds in showing
   WaitForSingleObjectEx as the caller of ntdll!ZwWaitForSingleObject.
   Why can't it continue from there?  Unless someone can prove to us (by
   disassemblying at that spot) that the functions which give us trouble
   are frameless, I'm not sure we should dismiss this case so easily.

Joel and I looked at the disassembled code, it's a complicated
function that defenitely doesn't set up a proper frame.

   > The code looks like hand-optimized assembler.

   Btw, Joel, could you please see if GDB 5.x did succeed to show a good
   backtrace in this very case?

It (silently) skipped a few frames.

   Anyway, the real reason I said what I did was that I see something
   very similar in a DJGPP-compiled Emacs; see below.  Now this is pure
   GCC code and DJGPP runtime, no Microsoft shit anywhere in sight, and I
   can tell you with 100% certainty that no hand-optimized assembly is
   used anywhere in the frames that are misbehaving in GDB.  It's all
   part of Emacs sources written in C, you can actually look up the
   sources in the Emacs codebase.  Doesn't it look similar to what Joel
   posted?

In some ways, yes.  GDB loses track after frame #21, but I doubt
whether recursive_edit_1 is a frameless function.  Can you post a
dissassembly of that function?

Mark

Re: [6.2] PROBLEMS file

[Eli Zaretskii]

> Date: Thu, 22 Jul 2004 21:26:18 +0200 (CEST)
> From: Mark Kettenis <kettenis@chello.nl>
> 
>    Date: Thu, 22 Jul 2004 22:11:06 +0200
>    From: "Eli Zaretskii" <eliz@gnu.org>
> 
>    >     #0  0x7ffe0304 in ?? ()
>    >     #1  0x77f7f4af in ntdll!ZwWaitForSingleObject () from ntdll.dll
>    >     #2  0x77e7788b in WaitForSingleObjectEx () from /WINDOWS/system32/KERNEL32.DLL
>    >     #3  0x00000778 in ?? ()
>    >     #4  0x00000000 in ?? () from 
>    >     #5  0x010df2c8 in ?? ()
>    >     #6  0x000003e8 in ?? ()
>    >     [snip]
>    >     Previous frame inner to this frame (corrupt stack?)
>    > 
>    > In the backtrace above, only frame 0 to 2 are correct. After that,
>    > GDB goes in limbo until it finally finds out that something is wrong.
> 
>    That is exactly what I saw with the DJGPP port.  Was the program in
>    your case compiled with DWARF2 debug info or with some other format?
> 
> Look at the backtrace Eli.

I did.  It's possible that I misunderstand something, or even make
some stupid mistake, but there's no need to assume I didn't read the
message to which I responded.

> Frame #2 is executing Microsoft shit.  I
> don't know what debugging format they use, and I don't think they ship
> their official releases with debugging info in it.

Sorry, I fail to see the relevance of this.  No matter what debug info
is there, GDB should be able to track stack frames, shouldn't it?  And
it actually does at least once: it succeeds in showing
WaitForSingleObjectEx as the caller of ntdll!ZwWaitForSingleObject.
Why can't it continue from there?  Unless someone can prove to us (by
disassemblying at that spot) that the functions which give us trouble
are frameless, I'm not sure we should dismiss this case so easily.

> The code looks like hand-optimized assembler.

This needs a proof (unless you already looked at the machine code, in
which case please show it).  In my experience, most of the ``Microsoft
shit'' is bad C with classic stack frames, not frameless
hand-optimized assembly.

Btw, Joel, could you please see if GDB 5.x did succeed to show a good
backtrace in this very case?

Anyway, the real reason I said what I did was that I see something
very similar in a DJGPP-compiled Emacs; see below.  Now this is pure
GCC code and DJGPP runtime, no Microsoft shit anywhere in sight, and I
can tell you with 100% certainty that no hand-optimized assembly is
used anywhere in the frames that are misbehaving in GDB.  It's all
part of Emacs sources written in C, you can actually look up the
sources in the Emacs codebase.  Doesn't it look similar to what Joel
posted?

This is a snapshot of a session with GDB 5.1.1:

d:\gnu\new\emacs\src> gdb ./emacs
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-pc-msdosdjgpp"...
Environment variable "DISPLAY" not defined.
Breakpoint 1 at 0x10b765: file msdos.c, line 4960.
(gdb) b q
(gdb) b dos_rawgetc
Breakpoint 2 at 0x108da0: file msdos.c, line 2263.
(gdb) r -q
Starting program: d:/gnu/new/emacs/src/./emacs -q

Breakpoint 2, 0x00108da0 in dos_rawgetc () at msdos.c:2263
2263	{
(gdb) c
Continuing.

Breakpoint 2, 0x00108da0 in dos_rawgetc () at msdos.c:2263
2263	{
(gdb) bt
#0  0x00108da0 in dos_rawgetc () at msdos.c:2263
#1  0x001098ac in dos_keysns () at msdos.c:2263
#2  0x000672b4 in read_avail_input (expected=0) at keyboard.c:6683
#3  0x0006718e in get_filtered_input_pending (addr=0x36d980, do_timers_now=1, 
    filter_events=1) at keyboard.c:6535
#4  0x0006ba7b in Finput_pending_p () at keyboard.c:9931
#5  0x000c6cda in Ffuncall (nargs=1, args=0x6de810) at eval.c:2725
#6  0x000f1b48 in Fbyte_code (bytestr=2106667, vector=2107772, maxdepth=96)
    at bytecode.c:689
#7  0x000c6ff5 in funcall_lambda (fun=2106636, nargs=1, arg_vector=0x6de944)
    at eval.c:2915
#8  0x000c6b9a in Ffuncall (nargs=2, args=0x6de940) at eval.c:2785
#9  0x000f1b48 in Fbyte_code (bytestr=2090427, vector=2091700, maxdepth=48)
    at bytecode.c:689
#10 0x000c6ff5 in funcall_lambda (fun=2090404, nargs=0, arg_vector=0x6dea64)
    at eval.c:2915
#11 0x000c6b9a in Ffuncall (nargs=1, args=0x6dea60) at eval.c:2785
#12 0x000f1b48 in Fbyte_code (bytestr=2085195, vector=2085348, maxdepth=48)
    at bytecode.c:689
#13 0x000c6ff5 in funcall_lambda (fun=2085172, nargs=0, arg_vector=0x6deb20)
    at eval.c:2915
#14 0x000c6e63 in apply_lambda (fun=2085172, args=3792897, eval_flag=1)
    at eval.c:2837
#15 0x000c600f in Feval (form=5387093) at eval.c:2138
#16 0x0005fd92 in top_level_2 () at keyboard.c:1302
#17 0x000c4edd in internal_condition_case (bfun=0x5fd80 <top_level_2>, 
    handlers=3865009, hfun=0x5fa80 <cmd_error>) at eval.c:1335
#18 0x0005fe41 in top_level_1 () at keyboard.c:1310
#19 0x000c49fa in internal_catch (tag=3858225, func=0x5fe10 <top_level_1>, 
    arg=3792897) at eval.c:1096
#20 0x0005fcf8 in command_loop () at keyboard.c:1267
#21 0x0005f81d in recursive_edit_1 () at keyboard.c:978
#22 0x0005f955 in Frecursive_edit () at keyboard.c:1039
#23 0x0005dce8 in main (argc=2, argv=0x396b80) at emacs.c:1687
#24 0x00117092 in __crt1_startup ()
(gdb) q
The program is running.  Exit anyway? (y or n) y
d:\gnu\new\emacs\src>

And this is the same session, for the same Emacs binary, with GDB 6.1:

d:\gnu\new\emacs\src> gdb6_1 ./emacs
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i386-pc-msdosdjgpp --target=djgpp"...
Environment variable "DISPLAY" not defined.
Breakpoint 1 at 0x10b765: file msdos.c, line 4960.
(gdb) b dos_rawgetc
Breakpoint 2 at 0x108da5: file msdos.c, line 2263.
(gdb) r -q
Starting program: d:/gnu/new/emacs/src/./emacs -q

Breakpoint 2, 0x00108da5 in dos_rawgetc () at msdos.c:2263
2263	{
(gdb) c
Continuing.

Breakpoint 2, 0x00108da5 in dos_rawgetc () at msdos.c:2263
2263	{
(gdb) bt
#0  0x00108da5 in dos_rawgetc () at msdos.c:2263
#1  0x001098ac in dos_keysns () at msdos.c:2263
#2  0x000672b4 in read_avail_input (expected=0) at keyboard.c:6683
#3  0x0006718e in get_filtered_input_pending (addr=0x36d980, do_timers_now=1, 
    filter_events=1) at keyboard.c:6535
#4  0x0006ba7b in Finput_pending_p () at keyboard.c:9931
#5  0x000c6cda in Ffuncall (nargs=1, args=0x6de810) at eval.c:2725
#6  0x000f1b48 in Fbyte_code (bytestr=2106667, vector=2107772, maxdepth=96)
    at bytecode.c:689
#7  0x000c6ff5 in funcall_lambda (fun=2106636, nargs=1, arg_vector=0x6de944)
    at eval.c:2915
#8  0x000c6b9a in Ffuncall (nargs=2, args=0x6de940) at eval.c:2785
#9  0x000f1b48 in Fbyte_code (bytestr=2090427, vector=2091700, maxdepth=48)
    at bytecode.c:689
#10 0x000c6ff5 in funcall_lambda (fun=2090404, nargs=0, arg_vector=0x6dea64)
    at eval.c:2915
#11 0x000c6b9a in Ffuncall (nargs=1, args=0x6dea60) at eval.c:2785
#12 0x000f1b48 in Fbyte_code (bytestr=2085195, vector=2085348, maxdepth=48)
    at bytecode.c:689
#13 0x000c6ff5 in funcall_lambda (fun=2085172, nargs=0, arg_vector=0x6deb20)
    at eval.c:2915
#14 0x000c6e63 in apply_lambda (fun=2085172, args=3792897, eval_flag=1)
    at eval.c:2837
#15 0x000c600f in Feval (form=5387093) at eval.c:2138
#16 0x0005fd92 in top_level_2 () at keyboard.c:1302
#17 0x000c4edd in internal_condition_case (bfun=0x5fd80 <top_level_2>, 
    handlers=3865009, hfun=0x5fa80 <cmd_error>) at eval.c:1335
#18 0x0005fe41 in top_level_1 () at keyboard.c:1310
#19 0x000c49fa in internal_catch (tag=3858225, func=0x5fe10 <top_level_1>, 
    arg=3792897) at eval.c:1096
#20 0x0005fcf8 in command_loop () at keyboard.c:1267
#21 0x0005f81d in recursive_edit_1 () at keyboard.c:978
#22 0x0039e001 in end ()
#23 0x0039e001 in end ()
#24 0x0039e001 in end ()
#25 0x00000000 in ?? ()
#26 0x00000000 in ?? ()
#27 0x006def08 in ?? ()
#28 0x0005f955 in Frecursive_edit () at keyboard.c:1039
Previous frame inner to this frame (corrupt stack?)
(gdb) q
The program is running.  Exit anyway? (y or n) y
d:\gnu\new\emacs\src>

Re: [6.2] PROBLEMS file

[H. J. Lu]

On Thu, Jul 22, 2004 at 10:51:48PM +0200, Mark Kettenis wrote:
>    Date: Wed, 21 Jul 2004 14:16:32 -0700
>    From: "H. J. Lu" <hjl@lucon.org>
> 
>    FYI, the i386 psABI, which is also used by the x86-64 psABI, says:
> 
>    %ebp	The content of this register is unspecified at process
> 	   initialization time, but the user code should mark the
> 	   deepest stack frame by setting the frame pointer to zero.
> 	   No other frame's %ebp should have a zero value.
> 
> Which contradicts the optional nature of %ebp as a frame pointer.  So
> the standard contradicts itself.  Anyway, in practice the %ebp == 0
> condition is useless.

Not at all. Standard is quite clear to me. According to i386 psABI,
%ebp has to be preserved for the caller. If the first instruction of a
function in an ABI compliant application is to clear %ebp, it must be
marking the deepest stack frame.

But I can be convinced if you can show me an example otherwise.


H.J.

Re: [6.2] PROBLEMS file

[Joel Brobecker]

FWIW: As a user, I don't mind when the unwinder goes too far and
displays too many frames. The info we're looking for is there, and
that's what really counts for me. Not pretty, but good enough.
So I wouldn't mind closing that particular PR, especially since
there doesn't seem to be any accurate way of detecting the top
of the call stack.

-- 
Joel

Re: [6.2] PROBLEMS file

[Mark Kettenis]

   Date: Wed, 21 Jul 2004 14:16:32 -0700
   From: "H. J. Lu" <hjl@lucon.org>

   FYI, the i386 psABI, which is also used by the x86-64 psABI, says:

   %ebp	The content of this register is unspecified at process
	   initialization time, but the user code should mark the
	   deepest stack frame by setting the frame pointer to zero.
	   No other frame's %ebp should have a zero value.

Which contradicts the optional nature of %ebp as a frame pointer.  So
the standard contradicts itself.  Anyway, in practice the %ebp == 0
condition is useless.

Mark

Re: [6.2] PROBLEMS file

[Mark Kettenis]

   Date: Thu, 22 Jul 2004 22:11:06 +0200
   From: "Eli Zaretskii" <eliz@gnu.org>

   >     #0  0x7ffe0304 in ?? ()
   >     #1  0x77f7f4af in ntdll!ZwWaitForSingleObject () from ntdll.dll
   >     #2  0x77e7788b in WaitForSingleObjectEx () from /WINDOWS/system32/KERNEL32.DLL
   >     #3  0x00000778 in ?? ()
   >     #4  0x00000000 in ?? () from 
   >     #5  0x010df2c8 in ?? ()
   >     #6  0x000003e8 in ?? ()
   >     [snip]
   >     Previous frame inner to this frame (corrupt stack?)
   > 
   > In the backtrace above, only frame 0 to 2 are correct. After that,
   > GDB goes in limbo until it finally finds out that something is wrong.

   That is exactly what I saw with the DJGPP port.  Was the program in
   your case compiled with DWARF2 debug info or with some other format?

Look at the backtrace Eli.  Frame #2 is executing Microsoft shit.  I
don't know what debugging format they use, and I don't think they ship
their official releases with debugging info in it.

The code looks like hand-optimized assembler.  There is no hope our
unwinder can make any sense out of it without some major work.  The
only thing that makes sense is somehow trust %ebp to point to some
valid frame.  There is no guarantee that it doesn't point to some
garbage and if we trust it, we'll probably skip more a few frames in
the backtrace.  That's why it won't be the default.

Mark

Re: [6.2] PROBLEMS file

[Eli Zaretskii]

> Date: Thu, 22 Jul 2004 08:17:01 -0700
> From: Joel Brobecker <brobecker@gnat.com>
> 
> We saw the same sort of issues on Windows as well, trying to unwind
> from functions in the ntdll DLL. Unfortunately in that case, we don't
> get an infinite backtrace, we get a backtrace that doesn't provide
> the part that the user is probably looking for (the part refering to
> his code, before the call to the ntdll services). Something like this:
> 
>     #0  0x7ffe0304 in ?? ()
>     #1  0x77f7f4af in ntdll!ZwWaitForSingleObject () from ntdll.dll
>     #2  0x77e7788b in WaitForSingleObjectEx () from /WINDOWS/system32/KERNEL32.DLL
>     #3  0x00000778 in ?? ()
>     #4  0x00000000 in ?? () from 
>     #5  0x010df2c8 in ?? ()
>     #6  0x000003e8 in ?? ()
>     [snip]
>     #27 0x77e79d6a in WaitForSingleObject () from /WINDOWS/system32/KERNEL32.DLL
>     #28 0x00000778 in ?? ()
>     #29 0x000003e8 in ?? ()
>     #30 0x00000000 in ?? () from 
>     #31 0x61074971 in siginterrupt () from /bin/cygwin1.dll
>     Previous frame inner to this frame (corrupt stack?)
> 
> In the backtrace above, only frame 0 to 2 are correct. After that,
> GDB goes in limbo until it finally finds out that something is wrong.

That is exactly what I saw with the DJGPP port.  Was the program in
your case compiled with DWARF2 debug info or with some other format?

Re: [6.2] PROBLEMS file

[Joel Brobecker]

> Mark Kettenis writes:
> > There will always be cases where GDB will get confused and lose track.
> > In that case it will possibly provide an endless or very long backtrace
> > containing garbage.
> 
> I'm okay with this part, as long as the user can easily get it
> out of it at the "press space to continue" prompt.  

We saw the same sort of issues on Windows as well, trying to unwind
from functions in the ntdll DLL. Unfortunately in that case, we don't
get an infinite backtrace, we get a backtrace that doesn't provide
the part that the user is probably looking for (the part refering to
his code, before the call to the ntdll services). Something like this:

    #0  0x7ffe0304 in ?? ()
    #1  0x77f7f4af in ntdll!ZwWaitForSingleObject () from ntdll.dll
    #2  0x77e7788b in WaitForSingleObjectEx () from /WINDOWS/system32/KERNEL32.DLL
    #3  0x00000778 in ?? ()
    #4  0x00000000 in ?? () from 
    #5  0x010df2c8 in ?? ()
    #6  0x000003e8 in ?? ()
    [snip]
    #27 0x77e79d6a in WaitForSingleObject () from /WINDOWS/system32/KERNEL32.DLL
    #28 0x00000778 in ?? ()
    #29 0x000003e8 in ?? ()
    #30 0x00000000 in ?? () from 
    #31 0x61074971 in siginterrupt () from /bin/cygwin1.dll
    Previous frame inner to this frame (corrupt stack?)

In the backtrace above, only frame 0 to 2 are correct. After that,
GDB goes in limbo until it finally finds out that something is wrong.
The backtrace doesn't show how you got there, and I can imagine that
it could be fustrating for a user.

I have been working on and off on a small patch that would allow the
user to tell GDB to trust %ebp instead of trying to read the prologue
and guess the location of the return address for frameless functions.
The idea would be to offer this alternative when the current unwinder
fails.

I have a pretty simple minded patch that seems to be more or less
working, but I still have ~200 regressions compared to the current
unwinder. I would like to have a look at them, and if possible fix
them, before I submit what I have for review.

-- 
Joel

Re: [6.2] PROBLEMS file

[Daniel Jacobowitz]

On Thu, Jul 22, 2004 at 01:13:19PM +0100, Dave Korn wrote:
> > -----Original Message-----
> > From: gdb-owner On Behalf Of Mark Kettenis
> > Sent: 21 July 2004 22:00
> 
> > shouldn't terminate the backtrace.  And %eip == 0 can happen in the
> > case of a null-pointer function call.
> 
>   Does it?  I thought the stored eip on the stack points to the return
> address of the caller, which is the byte after the call instruction, so eip
> = 0 would only occur in a stack frame if there was a call instruction at
> 0xfffffffb that had just been executed?

Consider a SIGSEGV handler invoked in response to a NULL pointer call.

-- 
Daniel Jacobowitz

RE: [6.2] PROBLEMS file

[Dave Korn]

> -----Original Message-----
> From: gdb-owner On Behalf Of Mark Kettenis
> Sent: 21 July 2004 22:00

> shouldn't terminate the backtrace.  And %eip == 0 can happen in the
> case of a null-pointer function call.

  Does it?  I thought the stored eip on the stack points to the return
address of the caller, which is the byte after the call instruction, so eip
= 0 would only occur in a stack frame if there was a call instruction at
0xfffffffb that had just been executed?

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: [6.2] PROBLEMS file

[Michael Elizabeth Chastain]

Mark Kettenis writes:
> There will always be cases where GDB will get confused and lose track.
> In that case it will possibly provide an endless or very long backtrace
> containing garbage.

I'm okay with this part, as long as the user can easily get it
out of it at the "press space to continue" prompt.  

It would be nice to have an adjustable cutoff defaulting to perhaps
1000 or 10,000 frames.  I've had some huge gdb.log files
(20 megabytes) because the test suite triggered such a bug and
then gdb wouldn't quit.

> So IMHO there is no regression here.  PR 1505 should be closed.

It's a regression if a specific sequence of commands works with
gdb N and does not work with gdb N+1.  You might have to say
"can't fix" or "won't fix".

Michael C

Re: [6.2] PROBLEMS file

[Eli Zaretskii]

> Date: Wed, 21 Jul 2004 18:05:34 -0400
> From: Andrew Cagney <cagney@gnu.org>
> 
> > So IMHO there is no regression here.  PR 1505 should be closed.  If
> > the length of the backtraces is a problem, we should probably set a
> > sensible backtrace limit.
> 
> Try and convince a user of that :-)  This is, right or wrong, a 
> situtation where we're the ones that get to push for a solution.

I tend to agree.

> To that end, two ideas:
> 
> - add a GNU extension to dwarf2 that identifies the frame as outer-most
> 
> - have the CFI unwinds back to the exact same identical frame (causing 
> GDB to throw up its hands)

This wouldn't help the DJGPP port of Emacs: it is compiled with
"-gcoff" (because no one has written code to support unexec with
DWARF2 debug info embedded in a COFF binary).

It would be much more helpful if someone could documente the inner
workings of the frame-unwinding code, including all its different
strategies, in gdbint.texinfo.  Perhaps then I could debug the problem
and at least understand what is causing it; I'm not at all sure it's
the function prologue/epilogue issue.

TIA

Re: [6.2] PROBLEMS file

[Andrew Cagney]

> So IMHO there is no regression here.  PR 1505 should be closed.  If
> the length of the backtraces is a problem, we should probably set a
> sensible backtrace limit.

Try and convince a user of that :-)  This is, right or wrong, a 
situtation where we're the ones that get to push for a solution.

To that end, two ideas:

- add a GNU extension to dwarf2 that identifies the frame as outer-most

- have the CFI unwinds back to the exact same identical frame (causing 
GDB to throw up its hands)

Andrew

Re: [6.2] PROBLEMS file

[H. J. Lu]

On Wed, Jul 21, 2004 at 10:59:42PM +0200, Mark Kettenis wrote:
>    Date: Mon, 19 Jul 2004 21:51:27 +0200
>    From: "Eli Zaretskii" <eliz@gnu.org>
> 
>    > Date: Sun, 18 Jul 2004 23:25:19 -0400
>    > From: Andrew Cagney <cagney@gnu.org>
>    > 
>    > gdb/1505: [regression] gdb prints a bad backtrace for a thread
>    > 
>    > When backtracing a thread, gdb does not stop when it reaches the
>    > outermost frame, instead continuing until it hits garbage.  This is
>    > sensitive to the operating system and thread library.
> 
> In most cases there is no way for GDB to tell what the outermost frame
> is.  Some people think that %ebp == 0 or %eip == 0 serves as a marker,
> but they're mistaken.  The usage as %ebp as a frame pointer is a
> software comvention which isn't mandated by the ABI.  More and more

FYI, the i386 psABI, which is also used by the x86-64 psABI, says:

%ebp	The content of this register is unspecified at process
	initialization time, but the user code should mark the
	deepest stack frame by setting the frame pointer to zero.
	No other frame's %ebp should have a zero value.


H.J.

Re: [6.2] PROBLEMS file

[Mark Kettenis]

   Date: Mon, 19 Jul 2004 21:51:27 +0200
   From: "Eli Zaretskii" <eliz@gnu.org>

   > Date: Sun, 18 Jul 2004 23:25:19 -0400
   > From: Andrew Cagney <cagney@gnu.org>
   > 
   > gdb/1505: [regression] gdb prints a bad backtrace for a thread
   > 
   > When backtracing a thread, gdb does not stop when it reaches the
   > outermost frame, instead continuing until it hits garbage.  This is
   > sensitive to the operating system and thread library.

In most cases there is no way for GDB to tell what the outermost frame
is.  Some people think that %ebp == 0 or %eip == 0 serves as a marker,
but they're mistaken.  The usage as %ebp as a frame pointer is a
software comvention which isn't mandated by the ABI.  More and more
code doesn't use %ebp as a frame pointer, makeing that register
available for other purposes.  In that case, %ebp == 0 defenitely
shouldn't terminate the backtrace.  And %eip == 0 can happen in the
case of a null-pointer function call.

   FWIW, I've seen similar problems without any threading, in the DJGPP
   port (when debugging Emacs).  GDB 5.x doesn't have problems with the
   same debuggee.  I originally thought that it is specific to DJGPP
   (perhaps because the DJGPP port of Emacs is compiled with -gcoff and
   the line number table overflows the 64K limit inherent to COFF debug
   info), but now that I see this PR, I begin to think that it's not
   DJGPP-specific.

We'll just have to live with this.  The days where we could trust the
"frame chain" on the i386 are over; there is too much frameless code
out there, and it will only increase.  Without DWARF2 CFI we have to
rely on the prologue analyzer to properly unwind the stack.  There
certainly is room for improvement in the prologue analyzer, but it
will probably never be perfect.  There will always be cases where GDB
will get confused and lose track.  In that case it will possibly
provide an endless or very long backtrace containing garbage.

So IMHO there is no regression here.  PR 1505 should be closed.  If
the length of the backtraces is a problem, we should probably set a
sensible backtrace limit.

Mark

Re: [6.2] PROBLEMS file

[Eli Zaretskii]

> Date: Sun, 18 Jul 2004 23:25:19 -0400
> From: Andrew Cagney <cagney@gnu.org>
> 
> gdb/1505: [regression] gdb prints a bad backtrace for a thread
> 
> When backtracing a thread, gdb does not stop when it reaches the
> outermost frame, instead continuing until it hits garbage.  This is
> sensitive to the operating system and thread library.

FWIW, I've seen similar problems without any threading, in the DJGPP
port (when debugging Emacs).  GDB 5.x doesn't have problems with the
same debuggee.  I originally thought that it is specific to DJGPP
(perhaps because the DJGPP port of Emacs is compiled with -gcoff and
the line number table overflows the 64K limit inherent to COFF debug
info), but now that I see this PR, I begin to think that it's not
DJGPP-specific.

Unfortunately, I didn't have enough time to debug this (one or two
attempts to find the reason didn't succeed, as I got bogged down in
the maze of frame-related function calls that jump back and forth
between platform-independent and target-specific code).

[6.2] PROBLEMS file

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 34 bytes --]

It needs some updates :-)

Andrew

[-- Attachment #2: PROBLEMS --]
[-- Type: text/plain, Size: 4749 bytes --]


			Known problems in GDB 6.2

		See also: http://www.gnu.org/software/gdb/bugs/


*** Build problems

build/1458: compile failed on hpux11

GDB has build problems on HP/UX 11 with some versions of the HP
Ansi C compiler.  (GCC works fine).

The problem happens when compiling intl/bindtextdom.c.
The error is:

  cc: "gettextP.h", line 50: error 1000: Unexpected symbol: "SWAP".
  cc: panic 2017: Cannot recover from earlier errors, terminating.
  *** Error exit code 1

This is a problem with the 'inline' keyword in gettextP.h.
The workaround is to disable 'inline' before building gdb:

  export ac_cv_c_inline=no

This problem happens only with some versions of the HP Ansi C compiler.
Versions A.11.01.25171.GP and B.11.11.28706.GP have both been observed
to work; version B.11.11.04 gets the build error and needs the
workaround.

This problem might also happen with other C compilers.

*** Misc

gdb/1560: Control-C does not always interrupt GDB.

When GDB is busy processing a command which takes a long time to
complete, hitting Control-C does not have the expected effect.
The command execution is not aborted, and the "QUIT" message confirming
the abortion is displayed only after the command has been completed.

*** C++ support

gdb/931: GDB could be more generous when reading types C++ templates on input

When the user types a template, GDB frequently requires the type to be
typed in a certain way (e.g. "const char*" as opposed to "const char *"
or "char const *" or "char const*").

gdb/1512: no canonical way to output names of C++ types

We currently don't have any canonical way to output names of C++ types.
E.g. "const char *" versus "char const *"; more subtleties arise when
dealing with templates.

gdb/1516: [regression] local classes, gcc 2.95.3, dwarf-2

With gcc 2.95.3 and the dwarf-2 debugging format, classes which are
defined locally to a function include the demangled name of the function
as part of their name.  For example, if a function "foobar" contains a
local class definition "Local", gdb will say that the name of the class
type is "foobar__Fi.0:Local".

This applies only to classes where the class type is defined inside a
function, not to variables defined with types that are defined somewhere
outside any function (which most types are).

gdb/1588: names of c++ nested types in casts must be enclosed in quotes

You must type
  (gdb) print ('Foo::Bar') x
or
  (gdb) print ('Foo::Bar' *) y
instead of
  (gdb) print (Foo::Bar) x
or
  (gdb) print (Foo::Bar *) y
respectively.

gdb/1091: Constructor breakpoints ignored
gdb/1193: g++ 3.3 creates multiple constructors: gdb 5.3 can't set breakpoints

When gcc 3.x compiles a C++ constructor or C++ destructor, it generates
2 or 3 different versions of the object code.  These versions have
unique mangled names (they have to, in order for linking to work), but
they have identical source code names, which leads to a great deal of
confusion.  Specifically, if you set a breakpoint in a constructor or a
destructor, gdb will put a breakpoint in one of the versions, but your
program may execute the other version.  This makes it impossible to set
breakpoints reliably in constructors or destructors.

gcc 3.x generates these multiple object code functions in order to
implement virtual base classes.  gcc 2.x generated just one object code
function with a hidden parameter, but gcc 3.x conforms to a multi-vendor
ABI for C++ which requires multiple object code functions.

*** Stack backtraces

GDB's core code base has been updated to use a new backtrace
mechanism.  This mechanism makes it possible to support new features
such DWARF 2 Call Frame Information (which in turn makes possible
backtraces through optimized code).

Since this code is new, it is known to still have a few problems:

gdb/1505: [regression] gdb prints a bad backtrace for a thread

When backtracing a thread, gdb does not stop when it reaches the
outermost frame, instead continuing until it hits garbage.  This is
sensitive to the operating system and thread library.

hppa*-*-*
mips*-*-*

The MIPS and HPPA backtrace code has only very recently been updated
to use GDB's new frame mechanism.  At present there are still a few
problems, in particular backtraces through signal handlers do not
work.

People encountering problems with these architectures should consult
GDB's web pages and mailing lists (http://www.gnu.org/software/gdb/)
to see if there are updates.

powerpc*-*-*

PowerPC architecture support, in 6.1, does not use the new frame code.

Fortunately, PowerPC architecture support, in GDB's mainline sources,
have been updated.  People encountering problems should consider
downloading a more current snapshot of GDB
(http://www.gnu.org/software/gdb/current/).