From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20041013 Firefox/0.9.3 (Ubuntu)
Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Build the to-be-attached program on a 32 bit machine
2. Run it on an x86_64 system
3. Attach to it with gdb
4. Print a backtrace
Actual Results: (gdb) bt
#0 0xffffe410 in ?? ()
#1 0xffffd878 in ?? ()
#2 0x00d2bff4 in ?? () from /lib/tls/libc.so.6
#3 0xffffd6d4 in ?? ()
#4 0x00c90d30 in __nanosleep_nocancel () from /lib/tls/libc.so.6
#5 0x00c90b53 in sleep () from /lib/tls/libc.so.6
Previous frame inner to this frame (corrupt stack?)
Expected Results: Something like what happens when I try to debug the
same program built for x86_64:
#0 0x0000003c0c68e992 in __nanosleep_nocancel () from
#1 0x0000003c0c68e840 in sleep () from /lib64/tls/libc.so.6
#2 0x00000000004005f3 in main (argc=0x1, argv=0x7fbffff808) at
Created attachment 110186 [details]
Example program. Build on ia32, run on x86_64.
That's a bug in gdb, not glibc.
If you step stepi out of the vDSO, you get the correct backtrace, so that sounds
like gdb not taking vDSO into account.
The vDSO seems to have correct unwind info as far as I can see:
The section .eh_frame contains:
00000000 00000014 00000000 CIE
Code alignment factor: 1
Data alignment factor: -4
Return address column: 8
Augmentation data: 1b
DW_CFA_def_cfa: r4 ofs 4
DW_CFA_offset: r8 at cfa-4
00000018 00000018 0000001c FDE cie=00000000 pc=ffffe400..ffffe410
DW_CFA_advance_loc: 1 to ffffe401
DW_CFA_offset: r5 at cfa-8
DW_CFA_advance_loc: 14 to ffffe40f
Disassembly of section .text.vsyscall:
ffffe400: 55 push %ebp
ffffe401: 89 cd mov %ecx,%ebp
ffffe403: 0f 05 syscall
ffffe405: b9 2b 00 00 00 mov $0x2b,%ecx
ffffe40a: 8e d1 mov %ecx,%ss
ffffe40c: 89 e9 mov %ebp,%ecx
ffffe40e: 5d pop %ebp
ffffe40f: c3 ret
(and if not, that would be a kernel bug, not glibc).
Created attachment 110523 [details]
A patch to support vDSO on x86_64
This patch seems to work for me.
I can't get that patch to work.
When I run the test program in a gdb that has your patch applied, this
is what happens:
johan@sthqa88:/usr/src/redhat/SOURCES$ gdb ~/src/test/sleepalot
GNU gdb Red Hat Linux (6.1post-1.20040607.62.johan1rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
welcome to change it and/or distribute copies of it under certain
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host
libthread_db library "/lib64/tls/libthread_db.so.1".
Starting program: /home/johan/src/test/sleepalot
Message from syslogd@sthqa88 at Fri Feb 11 14:54:21 2005 ...
sthqa88 kernel: invalid operand: 0000  SMP
Can you confirm that the patch should contain *no* code changes, but
only one change to how gdb is linked?
There are 2 bugs, gdb and kernel. See bug 146803.
Unforturnately bug 146803 is secret, so I can't see it :-(.
I submitted a kernel patch for bug 146803, which should be
GDB >= 126.96.36.199-0.28rh includes the required code.
That leaves the kernel problem.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.