Bug 516300
| Summary: | Debuginfo of the kernel which compiled with gcc-4.4.0 seems wrong | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Masami Hiramatsu <mhiramat> |
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 11 | CC: | jakub |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-09-29 13:12:20 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. |
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.