This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
cancel: [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #4 [Re: [revert] Regression on PowerPC]
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: gdb-patches at sourceware dot org
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>, Joel Brobecker <brobecker at adacore dot com>
- Date: Fri, 9 Mar 2012 08:21:25 +0100
- Subject: cancel: [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #4 [Re: [revert] Regression on PowerPC]
- References: <20120103155206.GM2730@adacore.com> <201201031444.q03Eir77009359@d06av02.portsmouth.uk.ibm.com> <20120104140104.GA22254@host2.jankratochvil.net> <20120308232345.GA32618@host2.jankratochvil.net>
On Fri, 09 Mar 2012 00:23:45 +0100, Jan Kratochvil wrote:
> 2012-03-09 Jan Kratochvil <jan.kratochvil@redhat.com>
>
> * amd64-linux-tdep.c: Include inferior.h.
> (amd64_linux_init_abi): Set ON_STACK and i386_linux_push_dummy_code.
> * i386-linux-tdep.c (i386_linux_push_dummy_code): New function.
> (i386_linux_init_abi): Set ON_STACK and i386_linux_push_dummy_code.
> * i386-tdep.h (i386_linux_push_dummy_code): New declaration.
FYI cancelling this patch, it has some issues:
(1) As i386-tdep.c already has OS-independent i386_push_dummy_call I believe
push_dummy_code can be also put into i386-tdep.c.
(2) At least on RHEL-5 i386 there is a regression:
FAIL: gdb.base/call-signal-resume.exp: continue to program exit
#0 null_hand_call () at ./gdb.base/call-signals.c:56
#1 <function called from gdb>
#2 0xf7fe0430 in __kernel_vsyscall ()
#3 0xf7e7d236 in kill () from /lib/libc.so.6
#4 0x080484f4 in gen_signal () at ./gdb.base/call-signals.c:35
#5 0x08048574 in main () at ./gdb.base/call-signals.c:81
->
#0 null_hand_call () at ./gdb.base/call-signals.c:56
#1 <function called from gdb>
#2 0xf7fe0430 in __kernel_vsyscall ()
#3 0xf7e7d236 in kill () from /lib/libc.so.6
#4 0xf70484f4 in ?? ()
#5 0x00004b03 in ?? ()
#6 0x00000006 in ?? ()
#7 0xffffd068 in ?? ()
#8 0x08048574 in main () at ./gdb.base/call-signals.c:81
This is because (a) the dummy frame has no associated DWARF/EH frame unwind
info and i386_push_dummy_call does not setup proper frame pointer in the new
frame. Moreover I believe it should be setup with 0 frame pointer / 0 return
address to indicate end of unwinding for possible inferior unwinders, IMO
inferior should not unwind through the dummy frame. And then therefore GDB
needs new frame_unwind to properly unwind that 0 return address / frame
pointer.
Regards,
Jan