On 09/03/2015 05:14 PM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Sep 03, 2015 at 02:35:55PM +0300, Adrian Hunter escreveu:
>> On 03/09/15 14:23, Jan Stancek wrote:
>>> Add -z parameter to avoid skipping zero blocks:
>>>
>>>  ffffffff816704fe <sysret_check+0x4b>:
>>>  ffffffff816704fe:  7b 34         jnp ffffffff81670534 <sysret_signal+0x1c>
>>>        ...
>>>  ffffffff81670501 <sysret_careful>:
>>>  ffffffff81670501:  0f ba e2 03   bt  $0x3,%edx
>>>  ffffffff81670505:  73 11         jae ffffffff81670518 <sysret_signal>
>>
>> Acked-by: Adrian Hunter <[email protected]>
> 
> Ok, I am applying this, but it would be nice to know in which systems,
> with which objdump/binutils versions which 'perf test' entry fails, with
> the output of such failure.
> 
> Jan, can you please provide this info?

Since my original report last year [1], I've seen it fail many times on
various HW (we run perf tests daily on RHEL). I haven't noticed any pattern
regarding HW it fails on.

Binutils versions go from binutils-2.23.52 to current latest from git.

It was always about "object code reading", from times it was perf test 21,
until now, when it's perf test 23.

I'm attaching examples of test output along with objdump output, that I
just ran on a random system using kernel 4.2.0.

HTH, regards,
Jan

[1] https://lkml.org/lkml/2014/12/11/222

HP ProLiant DL360p G8
Intel(R) Xeon(R) CPU E5-2640 v2 @ 2.00GHz
kernel 4.2.0

Example 1, binutils-2.23.52
----------------------------

# perf test 23 -v
23: Test object code reading                                 :
--- start ---
test child forked, pid 31014
Looking at the vmlinux_path (7 entries long)
Using /lib/modules/4.2.0/build/vmlinux for symbols
Parsing event 'cycles'
mmap size 528384B
<snip>
Reading object code for memory address: 0xffffffffa001c010
File is: /lib/modules/4.2.0/kernel/lib/libcrc32c.ko
On file address is: 0x80
dso open failed: No such file or directory
Objdump command is: objdump -d --start-address=0x10 --stop-address=0x90 
/lib/modules/4.2.0/kernel/lib/libcrc32c.ko
objdump read too few bytes
Reducing len to 120
Bytes read differ from those read by objdump
test child finished with -1
---- end ----
Test object code reading: FAILED!

# objdump -d --start-address=0x10 --stop-address=0x90 
/lib/modules/4.2.0/kernel/lib/libcrc32c.ko

/lib/modules/4.2.0/kernel/lib/libcrc32c.ko:     file format elf64-x86-64

Disassembly of section .text:

0000000000000010 <crc32c+0x10>:
  10:   8b 01                   mov    (%rcx),%eax
  12:   48 83 c0 26             add    $0x26,%rax
  16:   48 c1 e8 04             shr    $0x4,%rax
  1a:   48 c1 e0 04             shl    $0x4,%rax
  1e:   48 29 c4                sub    %rax,%rsp
  21:   48 8d 5c 24 07          lea    0x7(%rsp),%rbx
  26:   48 c1 eb 03             shr    $0x3,%rbx
  2a:   48 8d 04 dd 00 00 00    lea    0x0(,%rbx,8),%rax
  31:   00
  32:   89 3c dd 10 00 00 00    mov    %edi,0x10(,%rbx,8)
  39:   48 89 0c dd 00 00 00    mov    %rcx,0x0(,%rbx,8)
  40:   00
  41:   c7 04 dd 08 00 00 00    movl   $0x0,0x8(,%rbx,8)
  48:   00 00 00 00
  4c:   48 89 c7                mov    %rax,%rdi
  4f:   e8 00 00 00 00          callq  54 <crc32c+0x54>
  54:   85 c0                   test   %eax,%eax
  56:   75 0d                   jne    65 <crc32c+0x65>
  58:   8b 04 dd 10 00 00 00    mov    0x10(,%rbx,8),%eax
  5f:   48 8b 5d f8             mov    -0x8(%rbp),%rbx
  63:   c9                      leaveq
  64:   c3                      retq
  65:   0f 0b                   ud2
  67:   90                      nop

Disassembly of section .init.text:

0000000000000010 <init_module+0x10>:
  10:   00 00                   add    %al,(%rax)
  12:   00 00                   add    %al,(%rax)
  14:   31 d2                   xor    %edx,%edx
  16:   48 3d 01 f0 ff ff       cmp    $0xfffffffffffff001,%rax
  1c:   48 89 05 00 00 00 00    mov    %rax,0x0(%rip)        # 23 
<init_module+0x23>
  23:   0f 43 d0                cmovae %eax,%edx
  26:   89 d0                   mov    %edx,%eax
  28:   5d                      pop    %rbp
  29:   c3                      retq

Disassembly of section .exit.text:

0000000000000010 <cleanup_module+0x10>:
  10:   00 00                   add    %al,(%rax)
  12:   00 00                   add    %al,(%rax)
  14:   5d                      pop    %rbp
  15:   c3                      retq

Example 2, binutils-2.23.52
----------------------------

# perf test 23 -v
23: Test object code reading                                 :
--- start ---
test child forked, pid 34729
Looking at the vmlinux_path (7 entries long)
Using /lib/modules/4.2.0/build/vmlinux for symbols
Parsing event 'cycles'
mmap size 528384B
<snip>
Reading object code for memory address: 0xffffffff816829ac
File is: /lib/modules/4.2.0/build/vmlinux
On file address is: 0x8829ac
Objdump command is: objdump -d --start-address=0xffffffff816829ac 
--stop-address=0xffffffff81682a2c /lib/modules/4.2.0/build/vmlinux
Bytes read differ from those read by objdump
test child finished with -1
---- end ----
Test object code reading: FAILED!

# objdump -d --start-address=0xffffffff816829ac 
--stop-address=0xffffffff81682a2c /lib/modules/4.2.0/build/vmlinux

/lib/modules/4.2.0/build/vmlinux:     file format elf64-x86-64

Disassembly of section .text:

ffffffff816829ac <syscall_return_via_sysret+0x2e>:
ffffffff816829ac:       8c 35 00 ff 15 2b       mov    %?,0x2b15ff00(%rip)      
  # ffffffffac7e28b2 <__brk_limit+0x2a7e38b2>

ffffffff816829af <opportunistic_sysret_failed>:
ffffffff816829af:       ff 15 2b 8c 35 00       callq  *0x358c2b(%rip)        # 
ffffffff819db5e0 <pv_cpu_ops+0x120>
ffffffff816829b5:       e9 fe 08 00 00          jmpq   ffffffff816832b8 
<restore_c_regs_and_iret>
ffffffff816829ba:       66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)

ffffffff816829c0 <stub_clone>:
ffffffff816829c0:       4c 89 7c 24 08          mov    %r15,0x8(%rsp)
ffffffff816829c5:       4c 89 74 24 10          mov    %r14,0x10(%rsp)
ffffffff816829ca:       4c 89 6c 24 18          mov    %r13,0x18(%rsp)
ffffffff816829cf:       4c 89 64 24 20          mov    %r12,0x20(%rsp)
ffffffff816829d4:       48 89 6c 24 28          mov    %rbp,0x28(%rsp)
ffffffff816829d9:       48 89 5c 24 30          mov    %rbx,0x30(%rsp)
ffffffff816829de:       e9 3d e7 9f ff          jmpq   ffffffff81081120 
<SyS_clone>
ffffffff816829e3:       66 66 66 66 2e 0f 1f    data32 data32 data32 nopw 
%cs:0x0(%rax,%rax,1)
ffffffff816829ea:       84 00 00 00 00 00

ffffffff816829f0 <stub_fork>:
ffffffff816829f0:       4c 89 7c 24 08          mov    %r15,0x8(%rsp)
ffffffff816829f5:       4c 89 74 24 10          mov    %r14,0x10(%rsp)
ffffffff816829fa:       4c 89 6c 24 18          mov    %r13,0x18(%rsp)
ffffffff816829ff:       4c 89 64 24 20          mov    %r12,0x20(%rsp)
ffffffff81682a04:       48 89 6c 24 28          mov    %rbp,0x28(%rsp)
ffffffff81682a09:       48 89 5c 24 30          mov    %rbx,0x30(%rsp)
ffffffff81682a0e:       e9 ad e6 9f ff          jmpq   ffffffff810810c0 
<sys_fork>
ffffffff81682a13:       66 66 66 66 2e 0f 1f    data32 data32 data32 nopw 
%cs:0x0(%rax,%rax,1)
ffffffff81682a1a:       84 00 00 00 00 00

ffffffff81682a20 <stub_vfork>:
ffffffff81682a20:       4c 89 7c 24 08          mov    %r15,0x8(%rsp)
ffffffff81682a25:       4c 89 74 24 10          mov    %r14,0x10(%rsp)
ffffffff81682a2a:       4c 89 6c 24 18          mov    %r13,0x18(%rsp)


Example 3, latest objdump from git://sourceware.org/git/binutils-gdb.git
HEAD == 1a91555 Fix seg-fault in readelf when scanniing a corrupt binary.
over same data as previous example
--------------------------------------------------------------------------

# ./binutils/objdump -d --start-address=0xffffffff816829ac 
--stop-address=0xffffffff81682a2c /lib/modules/4.2.0/build/vmlinux

/lib/modules/4.2.0/build/vmlinux:     file format elf64-x86-64

Disassembly of section .text:

ffffffff816829ac <syscall_return_via_sysret+0x2e>:
ffffffff816829ac:       8c                      .byte 0x8c
ffffffff816829ad:       35                      .byte 0x35
        ...

ffffffff816829af <opportunistic_sysret_failed>:
ffffffff816829af:       ff 15 2b 8c 35 00       callq  *0x358c2b(%rip)        # 
ffffffff819db5e0 <pv_cpu_ops+0x120>
ffffffff816829b5:       e9 fe 08 00 00          jmpq   ffffffff816832b8 
<restore_c_regs_and_iret>
ffffffff816829ba:       66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)

ffffffff816829c0 <stub_clone>:
ffffffff816829c0:       4c 89 7c 24 08          mov    %r15,0x8(%rsp)
ffffffff816829c5:       4c 89 74 24 10          mov    %r14,0x10(%rsp)
ffffffff816829ca:       4c 89 6c 24 18          mov    %r13,0x18(%rsp)
ffffffff816829cf:       4c 89 64 24 20          mov    %r12,0x20(%rsp)
ffffffff816829d4:       48 89 6c 24 28          mov    %rbp,0x28(%rsp)
ffffffff816829d9:       48 89 5c 24 30          mov    %rbx,0x30(%rsp)
ffffffff816829de:       e9 3d e7 9f ff          jmpq   ffffffff81081120 
<SyS_clone>
ffffffff816829e3:       66 66 66 66 2e 0f 1f    data16 data16 data16 nopw 
%cs:0x0(%rax,%rax,1)
ffffffff816829ea:       84 00 00 00 00 00

ffffffff816829f0 <stub_fork>:
ffffffff816829f0:       4c 89 7c 24 08          mov    %r15,0x8(%rsp)
ffffffff816829f5:       4c 89 74 24 10          mov    %r14,0x10(%rsp)
ffffffff816829fa:       4c 89 6c 24 18          mov    %r13,0x18(%rsp)
ffffffff816829ff:       4c 89 64 24 20          mov    %r12,0x20(%rsp)
ffffffff81682a04:       48 89 6c 24 28          mov    %rbp,0x28(%rsp)
ffffffff81682a09:       48 89 5c 24 30          mov    %rbx,0x30(%rsp)
ffffffff81682a0e:       e9 ad e6 9f ff          jmpq   ffffffff810810c0 
<sys_fork>
ffffffff81682a13:       66 66 66 66 2e 0f 1f    data16 data16 data16 nopw 
%cs:0x0(%rax,%rax,1)
ffffffff81682a1a:       84 00 00 00 00 00

ffffffff81682a20 <stub_vfork>:
ffffffff81682a20:       4c 89 7c 24 08          mov    %r15,0x8(%rsp)
ffffffff81682a25:       4c 89 74 24 10          mov    %r14,0x10(%rsp)
ffffffff81682a2a:       4c                      rex.WR
ffffffff81682a2b:       89                      .byte 0x89

Reply via email to