[fedora-arm] Debugging/disassembly in F19

Florian Weimer fweimer at redhat.com
Tue Aug 6 08:49:07 UTC 2013


I'm looking at /usr/bin/newgrp in F19.  Specifically, I've set a 
breakpoint on xmalloc and stepped until the call to malloc in this function:

Dump of assembler code for function xmalloc:
    0xb6f07ffc <+0>:     push    {r4, r5, r6, lr}
    0xb6f08000 <+4>:     sub     sp, sp, #8
=> 0xb6f08004 <+8>:     bl      0xb6f05698
    0xb6f08008 <+12>:    ldr     r4, [pc, #104]  ; 0xb6f08078 <xmalloc+124>
    0xb6f0800c <+16>:    add     r4, pc, r4
    0xb6f08010 <+20>:    cmp     r0, #0
    0xb6f08014 <+24>:    beq     0xb6f08020 <xmalloc+36>
    0xb6f08018 <+28>:    add     sp, sp, #8
    0xb6f0801c <+32>:    pop     {r4, r5, r6, pc}
    0xb6f08020 <+36>:    ldr     r3, [pc, #84]   ; 0xb6f0807c <xmalloc+128>
    0xb6f08024 <+40>:    mov     r2, #5
    0xb6f08028 <+44>:    ldr     r1, [pc, #80]   ; 0xb6f08080 <xmalloc+132>
    0xb6f0802c <+48>:    ldr     r3, [r4, r3]
    0xb6f08030 <+52>:    add     r1, pc, r1
    0xb6f08034 <+56>:    ldr     r5, [r3]
    0xb6f08038 <+60>:    bl      0xb6f055cc
    0xb6f0803c <+64>:    ldr     r3, [pc, #64]   ; 0xb6f08084 <xmalloc+136>
    0xb6f08040 <+68>:    ldr     r3, [r4, r3]
    0xb6f08044 <+72>:    ldr     r4, [r3]
    0xb6f08048 <+76>:    mov     r6, r0
    0xb6f0804c <+80>:    bl      0xb6f05740
    0xb6f08050 <+84>:    ldr     r0, [r0]
    0xb6f08054 <+88>:    bl      0xb6f056b0
    0xb6f08058 <+92>:    mov     r3, r4
    0xb6f0805c <+96>:    mov     r2, r6
    0xb6f08060 <+100>:   mov     r1, #1
    0xb6f08064 <+104>:   str     r0, [sp]
    0xb6f08068 <+108>:   mov     r0, r5
    0xb6f0806c <+112>:   bl      0xb6f057b8
    0xb6f08070 <+116>:   mov     r0, #13
    0xb6f08074 <+120>:   bl      0xb6f056e0
    0xb6f08078 <+124>:   andeq   r10, r0, r0, ror lr
    0xb6f0807c <+128>:   andeq   r0, r0, r8, asr r1
    0xb6f08080 <+132>:   andeq   r1, r0, r8, ror #24
    0xb6f08084 <+136>:   andeq   r0, r0, r4, asr r1

As you can see, there is zero symbolic information.  I understand that 
presenting symbol offsets obtained indirectly from constant pools might 
be difficult, but even the simple direct calls aren't annotated.

On x86_64, the same function looks like this in GDB.

Dump of assembler code for function xmalloc:
    0x00007fac621c9890 <+0>:	push   %rbp
    0x00007fac621c9891 <+1>:	push   %rbx
    0x00007fac621c9892 <+2>:	sub    $0x8,%rsp
=> 0x00007fac621c9896 <+6>:	callq  0x7fac621c7470 <malloc at plt>
    0x00007fac621c989b <+11>:	test   %rax,%rax
    0x00007fac621c989e <+14>:	je     0x7fac621c98a7 <xmalloc+23>
    0x00007fac621c98a0 <+16>:	add    $0x8,%rsp
    0x00007fac621c98a4 <+20>:	pop    %rbx
    0x00007fac621c98a5 <+21>:	pop    %rbp
    0x00007fac621c98a6 <+22>:	retq
    0x00007fac621c98a7 <+23>:	callq  0x7fac621c71f0 <__errno_location at plt>
    0x00007fac621c98ac <+28>:	mov    (%rax),%edi
    0x00007fac621c98ae <+30>:	callq  0x7fac621c7600 <strerror at plt>
    0x00007fac621c98b3 <+35>:	mov    %rax,%rbp
    0x00007fac621c98b6 <+38>:	lea    0x203e0b(%rip),%rax        # 
0x7fac623cd6c8 <Prog>
    0x00007fac621c98bd <+45>:	lea    0x1cac(%rip),%rsi        # 
0x7fac621cb570
    0x00007fac621c98c4 <+52>:	mov    $0x5,%edx
    0x00007fac621c98c9 <+57>:	xor    %edi,%edi
    0x00007fac621c98cb <+59>:	mov    (%rax),%rbx
    0x00007fac621c98ce <+62>:	callq  0x7fac621c72a0 <dcgettext at plt>
    0x00007fac621c98d3 <+67>:	mov    %rax,%rdx
    0x00007fac621c98d6 <+70>:	mov    0x20371b(%rip),%rax        # 
0x7fac623ccff8
    0x00007fac621c98dd <+77>:	mov    %rbp,%r8
    0x00007fac621c98e0 <+80>:	mov    %rbx,%rcx
    0x00007fac621c98e3 <+83>:	mov    $0x1,%esi
    0x00007fac621c98e8 <+88>:	mov    (%rax),%rdi
    0x00007fac621c98eb <+91>:	xor    %eax,%eax
    0x00007fac621c98ed <+93>:	callq  0x7fac621c75c0 <__fprintf_chk at plt>
    0x00007fac621c98f2 <+98>:	mov    $0xd,%edi
    0x00007fac621c98f7 <+103>:	callq  0x7fac621c75a0 <exit at plt>
End of assembler dump.

-- 
Florian Weimer / Red Hat Product Security Team


More information about the arm mailing list