* Re: [6.2] PROBLEMS file @ 2004-07-22 12:14 Michael Elizabeth Chastain 2004-07-22 18:28 ` Joel Brobecker 0 siblings, 1 reply; 24+ messages in thread From: Michael Elizabeth Chastain @ 2004-07-22 12:14 UTC (permalink / raw) To: eliz, kettenis; +Cc: cagney, gdb 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-22 12:14 [6.2] PROBLEMS file Michael Elizabeth Chastain @ 2004-07-22 18:28 ` Joel Brobecker 2004-07-22 19:26 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Joel Brobecker @ 2004-07-22 18:28 UTC (permalink / raw) To: Michael Elizabeth Chastain; +Cc: eliz, kettenis, cagney, gdb > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-22 18:28 ` Joel Brobecker @ 2004-07-22 19:26 ` Eli Zaretskii 2004-07-22 20:51 ` Mark Kettenis 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2004-07-22 19:26 UTC (permalink / raw) To: Joel Brobecker; +Cc: mec.gnu, kettenis, cagney, gdb > 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? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-22 19:26 ` Eli Zaretskii @ 2004-07-22 20:51 ` Mark Kettenis 2004-07-23 9:24 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Mark Kettenis @ 2004-07-22 20:51 UTC (permalink / raw) To: eliz; +Cc: brobecker, mec.gnu, cagney, gdb 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-22 20:51 ` Mark Kettenis @ 2004-07-23 9:24 ` Eli Zaretskii 2004-07-23 11:22 ` Mark Kettenis 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2004-07-23 9:24 UTC (permalink / raw) To: Mark Kettenis; +Cc: brobecker, mec.gnu, cagney, gdb > 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> ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-23 9:24 ` Eli Zaretskii @ 2004-07-23 11:22 ` Mark Kettenis 2004-07-23 12:03 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Mark Kettenis @ 2004-07-23 11:22 UTC (permalink / raw) To: eliz; +Cc: brobecker, mec.gnu, cagney, gdb 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-23 11:22 ` Mark Kettenis @ 2004-07-23 12:03 ` Eli Zaretskii 2004-07-23 12:13 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Eli Zaretskii @ 2004-07-23 12:03 UTC (permalink / raw) To: Mark Kettenis; +Cc: brobecker, mec.gnu, cagney, gdb > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-23 12:03 ` Eli Zaretskii @ 2004-07-23 12:13 ` Eli Zaretskii 2004-07-23 12:16 ` Dave Korn 2004-07-23 13:36 ` Mark Kettenis 2 siblings, 0 replies; 24+ messages in thread From: Eli Zaretskii @ 2004-07-23 12:13 UTC (permalink / raw) To: kettenis; +Cc: brobecker, mec.gnu, cagney, gdb > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: [6.2] PROBLEMS file 2004-07-23 12:03 ` Eli Zaretskii 2004-07-23 12:13 ` Eli Zaretskii @ 2004-07-23 12:16 ` Dave Korn 2004-07-23 13:36 ` Mark Kettenis 2 siblings, 0 replies; 24+ messages in thread From: Dave Korn @ 2004-07-23 12:16 UTC (permalink / raw) To: 'Eli Zaretskii', 'Mark Kettenis', 'Steven Murdoch' Cc: brobecker, mec.gnu, cagney, gdb > -----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.... ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-23 12:03 ` Eli Zaretskii 2004-07-23 12:13 ` Eli Zaretskii 2004-07-23 12:16 ` Dave Korn @ 2004-07-23 13:36 ` Mark Kettenis 2004-07-23 16:17 ` Eli Zaretskii 2 siblings, 1 reply; 24+ messages in thread From: Mark Kettenis @ 2004-07-23 13:36 UTC (permalink / raw) To: eliz; +Cc: brobecker, mec.gnu, cagney, gdb 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-23 13:36 ` Mark Kettenis @ 2004-07-23 16:17 ` Eli Zaretskii 0 siblings, 0 replies; 24+ messages in thread From: Eli Zaretskii @ 2004-07-23 16:17 UTC (permalink / raw) To: Mark Kettenis; +Cc: gdb > 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?" ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file @ 2004-07-23 5:44 Michael Elizabeth Chastain 2004-07-23 20:44 ` Andrew Cagney 0 siblings, 1 reply; 24+ messages in thread From: Michael Elizabeth Chastain @ 2004-07-23 5:44 UTC (permalink / raw) To: brobecker, kettenis; +Cc: cagney, eliz, gdb, hjl 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-23 5:44 Michael Elizabeth Chastain @ 2004-07-23 20:44 ` Andrew Cagney 0 siblings, 0 replies; 24+ messages in thread From: Andrew Cagney @ 2004-07-23 20:44 UTC (permalink / raw) To: Michael Elizabeth Chastain; +Cc: brobecker, kettenis, eliz, gdb, hjl > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [6.2] PROBLEMS file @ 2004-07-19 3:51 Andrew Cagney 2004-07-19 21:01 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Andrew Cagney @ 2004-07-19 3:51 UTC (permalink / raw) To: gdb [-- 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/). ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-19 3:51 Andrew Cagney @ 2004-07-19 21:01 ` Eli Zaretskii 2004-07-21 21:12 ` Mark Kettenis 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2004-07-19 21:01 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb > 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). ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-19 21:01 ` Eli Zaretskii @ 2004-07-21 21:12 ` Mark Kettenis 2004-07-21 22:05 ` H. J. Lu ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Mark Kettenis @ 2004-07-21 21:12 UTC (permalink / raw) To: eliz; +Cc: cagney, gdb 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-21 21:12 ` Mark Kettenis @ 2004-07-21 22:05 ` H. J. Lu 2004-07-22 20:58 ` Mark Kettenis 2004-07-21 22:17 ` Andrew Cagney 2004-07-22 13:04 ` Dave Korn 2 siblings, 1 reply; 24+ messages in thread From: H. J. Lu @ 2004-07-21 22:05 UTC (permalink / raw) To: Mark Kettenis; +Cc: eliz, cagney, gdb 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-21 22:05 ` H. J. Lu @ 2004-07-22 20:58 ` Mark Kettenis 2004-07-22 21:33 ` Joel Brobecker 2004-07-22 21:38 ` H. J. Lu 0 siblings, 2 replies; 24+ messages in thread From: Mark Kettenis @ 2004-07-22 20:58 UTC (permalink / raw) To: hjl; +Cc: eliz, cagney, gdb 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-22 20:58 ` Mark Kettenis @ 2004-07-22 21:33 ` Joel Brobecker 2004-07-22 21:38 ` H. J. Lu 1 sibling, 0 replies; 24+ messages in thread From: Joel Brobecker @ 2004-07-22 21:33 UTC (permalink / raw) To: Mark Kettenis; +Cc: hjl, eliz, cagney, gdb 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-22 20:58 ` Mark Kettenis 2004-07-22 21:33 ` Joel Brobecker @ 2004-07-22 21:38 ` H. J. Lu 1 sibling, 0 replies; 24+ messages in thread From: H. J. Lu @ 2004-07-22 21:38 UTC (permalink / raw) To: Mark Kettenis; +Cc: eliz, cagney, gdb 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-21 21:12 ` Mark Kettenis 2004-07-21 22:05 ` H. J. Lu @ 2004-07-21 22:17 ` Andrew Cagney 2004-07-22 7:13 ` Eli Zaretskii 2004-07-22 13:04 ` Dave Korn 2 siblings, 1 reply; 24+ messages in thread From: Andrew Cagney @ 2004-07-21 22:17 UTC (permalink / raw) To: Mark Kettenis; +Cc: eliz, gdb > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-21 22:17 ` Andrew Cagney @ 2004-07-22 7:13 ` Eli Zaretskii 0 siblings, 0 replies; 24+ messages in thread From: Eli Zaretskii @ 2004-07-22 7:13 UTC (permalink / raw) To: Andrew Cagney; +Cc: kettenis, gdb > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: [6.2] PROBLEMS file 2004-07-21 21:12 ` Mark Kettenis 2004-07-21 22:05 ` H. J. Lu 2004-07-21 22:17 ` Andrew Cagney @ 2004-07-22 13:04 ` Dave Korn 2004-07-22 15:17 ` Daniel Jacobowitz 2 siblings, 1 reply; 24+ messages in thread From: Dave Korn @ 2004-07-22 13:04 UTC (permalink / raw) To: 'Mark Kettenis', eliz; +Cc: cagney, gdb > -----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.... ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6.2] PROBLEMS file 2004-07-22 13:04 ` Dave Korn @ 2004-07-22 15:17 ` Daniel Jacobowitz 0 siblings, 0 replies; 24+ messages in thread From: Daniel Jacobowitz @ 2004-07-22 15:17 UTC (permalink / raw) To: Dave Korn; +Cc: 'Mark Kettenis', eliz, cagney, gdb 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2004-07-23 19:31 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-07-22 12:14 [6.2] PROBLEMS file Michael Elizabeth Chastain 2004-07-22 18:28 ` Joel Brobecker 2004-07-22 19:26 ` Eli Zaretskii 2004-07-22 20:51 ` Mark Kettenis 2004-07-23 9:24 ` Eli Zaretskii 2004-07-23 11:22 ` Mark Kettenis 2004-07-23 12:03 ` Eli Zaretskii 2004-07-23 12:13 ` Eli Zaretskii 2004-07-23 12:16 ` Dave Korn 2004-07-23 13:36 ` Mark Kettenis 2004-07-23 16:17 ` Eli Zaretskii -- strict thread matches above, loose matches on Subject: below -- 2004-07-23 5:44 Michael Elizabeth Chastain 2004-07-23 20:44 ` Andrew Cagney 2004-07-19 3:51 Andrew Cagney 2004-07-19 21:01 ` Eli Zaretskii 2004-07-21 21:12 ` Mark Kettenis 2004-07-21 22:05 ` H. J. Lu 2004-07-22 20:58 ` Mark Kettenis 2004-07-22 21:33 ` Joel Brobecker 2004-07-22 21:38 ` H. J. Lu 2004-07-21 22:17 ` Andrew Cagney 2004-07-22 7:13 ` Eli Zaretskii 2004-07-22 13:04 ` Dave Korn 2004-07-22 15:17 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).