get_inst_lists: call targets shown in the disassembly are inconsistent

[xs-exp]

1. sometimes call addresses are virtual, sometimes they seem physical offsets
2. in the latter case, they are sometimes incorrect

Possibly related to #23 .

Example for 2: objdump (correct):

ffffffff811a2694:       e8 a7 26 46 00          callq  0xffffffff81604d40

chopper3 (correct):

        ilen 1, terminates: 0; push rbp
        ilen 3, terminates: 0; mov rbp, rsp
        ilen 5, terminates: 1; call 0x804d40  < < < <
[jmp] S PH 0x3a2699 VIRT 0xffffffff811a2699
[jmp] E PH 0x3a2698 VIRT 0xffffffff811a2698, UCOND: YES < < < <
[tgt] S 0x804d40  < < < <
[tgt] E 0x804d3f
[tgt] S PH 0x804d40 VIRT 0xffffffff81604d40  < < < <
[tgt] E PH 0x804d3f VIRT 0xffffffff81604d3f

get_inst_lists (INCORRECT):

In [1]: hex(3810960)
Out[1]: '0x3a2690'
(Note instruction offset == 4)
...
lookup_page_cgroup;3810960;4;vmlinux.elf;call 0x4626ac

[xs-exp]

This is possibly because the base is not supplied to the dump formatting instruction in xed.i:156

    void get_mnemonic_intel(char** buffer) {
        *buffer = (char*) malloc(64);
        xed_decoded_inst_dump_intel_format($self, *buffer, 64, 0);
    }

dump_intel_format needs to have a base provided https://software.intel.com/sites/landingpage/pintool/docs/65163/Xed/html/group__DEC.html#g28765b6bff0f31f06e3cc9231649d14e:

runtime_address the address of the instruction being disassembled. If zero, the offset is printed for relative branches. If nonzero, XED attempts to print the target address for relative branches.

[xs-exp]

Related to #16?