Description of problem: The debug information of some specific kernel functions(*) seems wrong. I found it that in kernel-PAE-2.6.29.6-213.fc11.i686 and also some kernel binaries generated by gcc-4.4.0. (*) currently, it seems that some "asmlinkage" functions will be effected. I dumped sys_epoll_wait of kernel-PAE-debuginfo with dwarfdump and objdump. Dwarfdump said: --- <1><48125> DW_TAG_subprogram DW_AT_external yes(1) DW_AT_name sys_epoll_wait DW_AT_decl_file 1 fs/eventpoll.c DW_AT_decl_line 1249 DW_AT_prototyped yes(1) DW_AT_type <172> DW_AT_low_pc 0xc04cc908 DW_AT_high_pc 0xc04ccc8b DW_AT_frame_base <loclist with 3 entries follows> [ 0]<lowpc=0xc04cc908><highpc=0xc04cc909>DW_OP_breg4+4 [ 1]<lowpc=0xc04cc909><highpc=0xc04cc90b>DW_OP_breg4+8 [ 2]<lowpc=0xc04cc90b><highpc=0xc04ccc8b>DW_OP_breg5+8 DW_AT_sibling <49424> <2><48155> DW_TAG_formal_parameter DW_AT_name epfd DW_AT_decl_file 1 fs/eventpoll.c DW_AT_decl_line 1249 DW_AT_type <96> DW_AT_location <loclist with 3 entries follows> [ 0]<lowpc=0xc04cc908><highpc=0xc04cc93f>DW_OP_breg1+0 [ 1]<lowpc=0xc04cc93f><highpc=0xc04cc96c>DW_OP_reg0 [ 2]<lowpc=0xc04cc96c><highpc=0xc04ccc8b>DW_OP_breg1+0 --- And objdump said: --- c04cc908 <sys_epoll_wait>: c04cc908: 55 push %ebp c04cc909: 89 e5 mov %esp,%ebp c04cc90b: 57 push %edi c04cc90c: 56 push %esi c04cc90d: 53 push %ebx c04cc90e: 51 push %ecx c04cc90f: 83 ec 60 sub $0x60,%esp c04cc912: 8d 4d 08 lea 0x8(%ebp),%ecx <---here! c04cc915: e8 4a d5 f3 ff call c0409e64 <mcount> c04cc91a: 8b 51 04 mov 0x4(%ecx),%edx c04cc91d: 8b 01 mov (%ecx),%eax c04cc91f: 8b 79 0c mov 0xc(%ecx),%edi c04cc922: 89 55 b0 mov %edx,-0x50(%ebp) c04cc925: 8b 71 08 mov 0x8(%ecx),%esi c04cc928: 89 f2 mov %esi,%edx c04cc92a: 4a dec %edx --- You can see that stack address is assigned to ecx at c04cc912. However, dwarf has no such information. Version-Release number of selected component (if applicable): gcc-4.4.0-4.i586 How reproducible: This problem can be reproduced by compiling kernel with gcc-4.4.0-4 I've compiled linux-2.6.31-rc4-tip and checked it. You can see the result on: http://sourceware.org/bugzilla/show_bug.cgi?id=10408#c8 Steps to Reproduce: 1. Install gcc-4.4.0-4 on x86-32 2. Compile linux kernel. 3. Compare the outputs of dwarfdump and objdump and check the local variable location. For example 'epfd' on sys_epoll_wait. Actual results: Some locations are wrong.(e.g. epfd on sys_epoll_wait) --- DW_AT_location <loclist with 3 entries follows> [ 0]<lowpc=0xc04cc908><highpc=0xc04cc93f>DW_OP_breg1+0 [ 1]<lowpc=0xc04cc93f><highpc=0xc04cc96c>DW_OP_reg0 [ 2]<lowpc=0xc04cc96c><highpc=0xc04ccc8b>DW_OP_breg1+0 --- Expected results: I assume that DW_AT_location of 'epfd' die should be following: --- DW_AT_location <loclist with 4 entries follows> [ 0]<lowpc=0xc04cc908><highpc=0xc04cc915>DW_OP_fbreg+0 [ 1]<lowpc=0xc04cc915><highpc=0xc04cc93f>DW_OP_breg1+0 [ 2]<lowpc=0xc04cc93f><highpc=0xc04cc96c>DW_OP_reg0 [ 3]<lowpc=0xc04cc96c><highpc=0xc04ccc8b>DW_OP_breg1+0 --- Additional info: This problem will effects all applications(gdb, systemtap, crash, etc.) which use debuginfo.
Please retry with a newer gcc (4.4.1-5), if it is present even there, I'll need a preprocessed testcase and all gcc command line options used to compile that function.
Where can I get that new gcc-4.4.1-5? I could get only gcc-4.4.1-3 from rawhide repository. BTW, the gcc-4.4.1-3 generated a broken dwarf (or newer dwarf4?), so I couldn't check it by dwarfdump. --- $ dwarfdump ~/kbin/2.6.31-rc6/vmlinux [snip] DW_AT_decl_line 10 DW_AT_sibling <655> <2>< 246> DW_TAG_member DW_AT_name orig_x DW_AT_decl_file 4 /home/mhiramat/ksrc/linux-2.6-tip/include/linux/screen_info.h DW_AT_decl_line 11 DW_AT_type <83> dwarfdump ERROR: dwarf_loclist: DW_DLE_ATTR_FORM_BAD (114) --- I've checked that happened with both of libdwarf-tools-0.20090324-5.fc12.i686 and the latest libdwarf (libdwarf-20090716.tar.gz). I hope it will not happen again with gcc-4.4.1-5. Thank you,
oops, it was dwarfdump's bug, eu-readelf --debug-dump can dump it, so gcc-4.4.1 did generate a normal dwarf. --- $ eu-readelf --debug-dump=info vmlinux [c1b67b] subprogram external name "sys_epoll_wait" decl_file 1 decl_line 1321 prototyped type [c11626] low_pc 0xc10b3d0d <sys_epoll_wait> high_pc 0xc10b3edb <sys_epoll_pwait> frame_base 1 byte block [ 0] call_frame_cfa sibling [c1b952] [c1b697] formal_parameter name "epfd" decl_file 1 decl_line 1321 type [c11504] location location list [ b7b85] $ eu-readelf --debug-dump=loc vmlinux [ b7b85] 0xc10b3d0d <sys_epoll_wait>..0xc10b3d6a <sys_epoll_wait+0x5d> [ 0] fbreg 0 0xc10b3d6a <sys_epoll_wait+0x5d>..0xc10b3ed1 <sys_epoll_wait+0x1c4> [ 0] breg5 8 0xc10b3ed1 <sys_epoll_wait+0x1c4>..0xc10b3edb <sys_epoll_pwait> [ 0] fbreg 0 --- and objdump said: --- c10b3d0d <sys_epoll_wait>: c10b3d0d: 55 push %ebp c10b3d0e: 89 e5 mov %esp,%ebp c10b3d10: 57 push %edi c10b3d11: 56 push %esi c10b3d12: 53 push %ebx c10b3d13: bb ea ff ff ff mov $0xffffffea,%ebx c10b3d18: 83 ec 38 sub $0x38,%esp c10b3d1b: 8b 45 10 mov 0x10(%ebp),%eax c10b3d1e: 8b 75 14 mov 0x14(%ebp),%esi c10b3d21: 48 dec %eax c10b3d22: 3d a9 aa aa 0a cmp $0xaaaaaa9,%eax c10b3d27: 0f 87 a4 01 00 00 ja c10b3ed1 <sys_epoll_wait+0x1c4> c10b3d2d: 89 e1 mov %esp,%ecx c10b3d2f: 8b 45 0c mov 0xc(%ebp),%eax c10b3d32: 6b 55 10 0c imul $0xc,0x10(%ebp),%edx c10b3d36: 81 e1 00 e0 ff ff and $0xffffe000,%ecx c10b3d3c: 01 d0 add %edx,%eax c10b3d3e: 19 db sbb %ebx,%ebx c10b3d40: 39 41 18 cmp %eax,0x18(%ecx) c10b3d43: 83 db 00 sbb $0x0,%ebx c10b3d46: 89 da mov %ebx,%edx c10b3d48: bb f2 ff ff ff mov $0xfffffff2,%ebx c10b3d4d: 85 d2 test %edx,%edx c10b3d4f: 0f 85 7c 01 00 00 jne c10b3ed1 <sys_epoll_wait+0x1c4> c10b3d55: 8b 45 08 mov 0x8(%ebp),%eax c10b3d58: b3 f7 mov $0xf7,%bl c10b3d5a: e8 e2 cf fd ff call c1090d41 <fget> c10b3d5f: 85 c0 test %eax,%eax c10b3d61: 89 45 d0 mov %eax,-0x30(%ebp) c10b3d64: 0f 84 67 01 00 00 je c10b3ed1 <sys_epoll_wait+0x1c4> c10b3d6a: 81 78 10 48 4f 43 c1 cmpl $0xc1434f48,0x10(%eax) --- So, gcc-4.4.1-3 seems to generate correct debug information. Thank you,
Closing as fixed in F12 then.