Re: [DynInst_API:] Basic basic block usage

[Bill Williams <bill@xxxxxxxxxxx>]

Marc--

That looks like a bug to me. Can you set the environment variable 
DYNINST_DEBUG_PARSING to 1, run your test, and send me the output that 
produces?
Thanks.

--bw

Bill Williams
Paradyn Project
bill@xxxxxxxxxxx

On 05/21/2013 07:12 AM, Marc Brünink wrote:
> Hi,
>
> I just started using Dyninst and have a small question regarding basic
> blocks.
>
> I have a micro test program that opens a file and reads some data from
> it. I am having issues with the basic blocks of the read function.
> Basically I'm missing 2 basic blocks.
>
> Using function.getCFG()->getAllBasicBlocks(bbs) I get the following
> basic blocks:
>
> Basic Block (7f17226f7890 to 7f17226f7899) (entry: 1) (exit: 0):
>          7f17226f7890    cmp [RIP + 2d793d], 0
>          7f17226f7897    jnz 10 + RIP + 2
> Basic Block (7f17226f78a9 to 7f17226f78b2) (entry: 0) (exit: 0):
>          7f17226f78a9    sub RSP, 8
>          7f17226f78ad    call 1b13e + RIP + 5
> Basic Block (7f17226f78b2 to 7f17226f78c9) (entry: 0) (exit: 0):
>          7f17226f78b2    mov [ESP], RAX
>          7f17226f78b6    mov RAX, 0
>          7f17226f78bb    syscall RCX
>          7f17226f78bd    mov RDI, [ESP]
>          7f17226f78c1    mov RDX, RAX
>          7f17226f78c4    call 1b187 + RIP + 5
> Basic Block (7f17226f78c9 to 7f17226f78d8) (entry: 0) (exit: 0):
>          7f17226f78c9    mov RAX, RDX
>          7f17226f78cc    add RSP, 8
>          7f17226f78d0    cmp RAX, fffff001
>          7f17226f78d6    jnb/jae/j 1 + RIP + 2
> Basic Block (7f17226f78d8 to 7f17226f78d9) (entry: 0) (exit: 1):
>          7f17226f78d8    ret near [RSP]
> Basic Block (7f17226f78d9 to 7f17226f78ee) (entry: 0) (exit: 0):
>          7f17226f78d9    mov RCX, [RIP + 2d1540]
>          7f17226f78e0    xor RDX, RDX
>          7f17226f78e2    sub RDX, RAX
>          7f17226f78e5    mov [RCX], RDX
>          7f17226f78e8    or RAX, ff
>          7f17226f78ec    jmp ffffffffffffffea + RIP + 2
>
>
> Using GDB I get this:
>
>     0x00007ffff7b01890 <+0>:     cmpl   $0x0,0x2d793d(%rip)        #
> 0x7ffff7dd91d4
> => 0x00007ffff7b01897 <+7>:     jne    0x7ffff7b018a9 <read+25>
>     0x00007ffff7b01899 <+9>:     mov    $0x0,%eax
>     0x00007ffff7b0189e <+14>:    syscall
>     0x00007ffff7b018a0 <+16>:    cmp    $0xfffffffffffff001,%rax
>     0x00007ffff7b018a6 <+22>:    jae    0x7ffff7b018d9 <read+73>
>     0x00007ffff7b018a8 <+24>:    retq
>     0x00007ffff7b018a9 <+25>:    sub    $0x8,%rsp
>     0x00007ffff7b018ad <+29>:    callq  0x7ffff7b1c9f0
>     0x00007ffff7b018b2 <+34>:    mov    %rax,(%rsp)
>     0x00007ffff7b018b6 <+38>:    mov    $0x0,%eax
>     0x00007ffff7b018bb <+43>:    syscall
>     0x00007ffff7b018bd <+45>:    mov    (%rsp),%rdi
>     0x00007ffff7b018c1 <+49>:    mov    %rax,%rdx
>     0x00007ffff7b018c4 <+52>:    callq  0x7ffff7b1ca50
>     0x00007ffff7b018c9 <+57>:    mov    %rdx,%rax
>     0x00007ffff7b018cc <+60>:    add    $0x8,%rsp
>     0x00007ffff7b018d0 <+64>:    cmp    $0xfffffffffffff001,%rax
>     0x00007ffff7b018d6 <+70>:    jae    0x7ffff7b018d9 <read+73>
>     0x00007ffff7b018d8 <+72>:    retq
>     0x00007ffff7b018d9 <+73>:    mov    0x2d1540(%rip),%rcx        #
> 0x7ffff7dd2e20
>     0x00007ffff7b018e0 <+80>:    xor    %edx,%edx
>     0x00007ffff7b018e2 <+82>:    sub    %rax,%rdx
>     0x00007ffff7b018e5 <+85>:    mov    %edx,%fs:(%rcx)
>     0x00007ffff7b018e8 <+88>:    or     $0xffffffffffffffff,%rax
>     0x00007ffff7b018ec <+92>:    jmp    0x7ffff7b018d8 <read+72>
>
>
> So I am basically missing the 2 blocks starting at 0x00007ffff7b01899
> and 0x00007ffff7b018a8.
>
> The edge between 0x00007ffff7b01890 and 0x00007ffff7b01899 is classified
> as an interprocedual tail call (why?). Shouldn't the block be still part
> of the function?
>
> Marc
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api