On 6/19/23 16:32, Vincent Mailhol wrote:
> On Mon 19 June 2023 at 21:16, Laszlo Ersek <ler...@redhat.com> wrote:
>> On 6/19/23 13:18, Vincent MAILHOL wrote:
>>> On Fri. 16 juin 2023 at 16:34, Richard W.M. Jones <rjo...@redhat.com> wrote:
>>> (...)
>>>>> Last thing, the segfault on ldmtool [1] still seems a valid issue.
>>>>> Even if I now do have a workaround for my problem, that segfault might
>>>>> be worth a bit more investigation.
>>>>
>>>> Yes that does look like a real problem. Does it crash if you just run
>>>> ldmtool as a normal command, nothing to do with libguestfs? Might be
>>>> a good idea to try to get a stack trace of the crash.
>>>
>>> The fact is that it only crashes with the UUID 65534 in the qemu VM. I
>>> am not sure what command line is passed to ldmtool for this crash to
>>> occur.
>>>
>>> I can help to gather information, but my biggest issue is that I do
>>> not know how to interact with the VM under /tmp/.guestfs-1001/
>>>
>>> [ 0.777352] ldmtool[164]: segfault at 0 ip 0000563a225cd6a5 sp
>>> 00007ffe54965a60 error 4 in ldmtool[563a225cb000+3000]
>>> ^^^^ ^^^^^^^^^^^^^^^^^^^
>>> This smells like a NULL pointer dereference.
>>
>> ... Hey this is actually my line from an email I started writing earlier
>> today :) , but I then decided not to send it.
>>
>> It certainly looks like a null pointer dereference, and if you
>> disassemble the instruction byte stream dump (the "Code:" line from the
>> kernel log) with (e.g.) ndisasm, that confirms it. You get something like
>>
>> 00000025 E8DBFDFFFF call 0xfffffffffffffe05
>> 0000002A 4C8B20 mov r12,[rax] <---- crash
>> 0000002D 4889442408 mov [rsp+0x8],rax
>> 00000032 4C89E7 mov rdi,r12
>> 00000035 E80BE1FFFF call 0xffffffffffffe145
>>
>> with the "mov r12,[rax]" instruction faulting (with the previously
>> called function presumably having returned 0 in rax). See the "<4c> 8b
>> 20" substring in the "Code:" line -- the angle brackets point at the
>> first byte of the crashing instruction.
>>
>> I didn't send the email ultimately because your email included a link
>> [1] pointing at a particular line number:
>>
>> https://github.com/mdbooth/libldm/blob/master/src/ldmtool.c#L164
>>
>> and so I assumed you actually traced the crash to that line.
>>
>> Is that the case?
>>
>> Or did you perhaps mistake *PID* 164 (from the kernel log) for the line
>> number?
>
> Yes, two messages back, I misinterpreted the PID (164) as a line
> number. Because that particular line manipulate the result of a
> g_array_index(), it looked coherent with the potential NULL pointer
> dereference. Realizing my mistake, I then started to do a deeper
> addr2line investigation in the previous message. Sorry.
>
>>> The instruction pointer
>>> being 563a225cd6a5, I installed libguestfs-tools-dbgsym and tried a:
>>>
>>> addr2line -e /usr/bin/ldmtool 564a892506a5
> ^^^^^^^^^^^^
>
> Reading my previous message, I do not know where this 564a892506a5
> comes from. I meant 563a225cd6a5 here (and below in gdb).
>
>>> Results:
>>>
>>> ??:0
>>>
>>> Without conviction, I also tried in GDB:
>>>
>>> $ gdb /usr/bin/ldmtool
>>> (...)
>>> Reading symbols from /usr/bin/ldmtool...
>>> Reading symbols from
>>> /usr/lib/debug/.build-id/21/37b4a64903ebe427c242be08b8d496ba570583.debug...
>>> (gdb) info line *0x564a892506a5
>>> No line number information available for address 0x564a892506a5
>>>
>>> Debug symbols are correctly installed but impossible to convert that
>>> instruction pointer into a line number. It is as if the ldmtool on my
>>> host and the ldmtool in the qemu VM were from a different build. I
>>> tried to mount /tmp/.guestfs-1001/appliance.d/root but that disk image
>>> did not contain ldmtool.
>>>
>>> I am not sure how to generate a stack trace or a core dump within that
>>> qemu VM. If you can tell me how to get an interactive prompt (or any
>>> other guidance) I can try to collect more information.
>>
>> The IP where the crash occurs is 0000563a225cd6a5. The ldmtool binary
>> (as opposed to a shared object / library) is mapped into the process's
>> address space at 563a225cb000, for a length of 0x3000 bytes. So the
>> offending instruction is supposed to be 0000563a225cd6a5 - 563a225cb000
>> = 26A5.
>
> Thanks for the explanation.
>
>> With the debug symbols installed, can you attach the output of
>>
>> objdump --headers --wide -S /usr/bin/ldmtool
>>
>> ?
>
> Results attached at the bottom of the e-mail.
>
>> Can you try
>>
>> addr2line -p -i -f -e /usr/bin/ldmtool 26A5
>>
>> ?
>
> Unfortunately:
>
> $ addr2line -p -i -f -e /usr/bin/ldmtool 26a5
> ?? ??:0
>
>> (This still may not be good enough; we might have to offset the
>> difference 0x26A5 with some address related to the .text section... The
>> objdump output should help us experiment.)
>
> For what it is worth, I loaded the program in GDB:
>
> (gdb) break main
> Breakpoint 1 at 0x3ba0: file ldmtool.c, line 756.
> (gdb) run
> Starting program: /usr/bin/ldmtool
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>
> Breakpoint 1, main (argc=1, argv=0x7fffffffdef8) at ldmtool.c:756
> 756 ldmtool.c: No such file or directory.
> (gdb) info proc map
> process 3968967
> Mapped address spaces:
>
> Start Addr End Addr Size Offset objfile
> 0x555555554000 0x555555557000 0x3000 0x0
> /usr/bin/ldmtool
> 0x555555557000 0x55555555a000 0x3000 0x3000
> /usr/bin/ldmtool
> 0x55555555a000 0x55555555b000 0x1000 0x6000
> /usr/bin/ldmtool
> 0x55555555c000 0x55555555d000 0x1000 0x7000
> /usr/bin/ldmtool
> 0x55555555d000 0x55555555e000 0x1000 0x8000
> /usr/bin/ldmtool
> 0x55555555e000 0x55555557f000 0x21000 0x0 [heap]
> 0x7ffff753b000 0x7ffff753f000 0x4000 0x0
> <shared object mapping redacted>
>
> I am not sure why there is five segment for ldmtool. Regardless:
>
> (gdb) info line *(0x555555554000 + 0x26a5)
> No line number information available for address 0x5555555566a5
> (gdb) info line *(0x555555557000 + 0x26a5)
> Line 717 of "ldmtool.c" starts at address 0x5555555596a5 <cmdline+245> and
> ends at 0x5555555596ad <cmdline+253>.
> (gdb) info line *(0x55555555a000 + 0x26a5)
> No line number information available for address 0x55555555c6a5
> (gdb) info line *(0x55555555c000 + 0x26a5)
> No line number information available for address 0x55555555e6a5
> (gdb) info line *(0x55555555d000 + 0x26a5)
> No line number information available for address 0x55555555f6a5
>
> On the latest version:
> https://github.com/mdbooth/libldm/blob/master/src/ldmtool.c#L717
> points to an empty line.
>
> But if I go a bit in the past (I am using Ubuntu 20.04)
>
> https://github.com/mdbooth/libldm/blob/5850aa5f060cd3a45d6d62c183261bba5096c0ed/src/ldmtool.c#L717
> looks like a smoking gun!
>
> I am not yet sure how I found it, but seems like we have a case
> closed.
>
> I will send a patch right away.
So the difference 0x26a5 is certainly good, it's just this weird offset
0x3000 that I can't explain (or deduce) from the objdump output. Note
that in the objdump output below, we don't have any usable 0x3000
reference. However, in your "info proc map" output above, we certainly
have it: the entry that starts at 0x555555557000, i.e. offset 0x3000.
That's the one relative to which you managed to deduce line 717, and
it's *also* the one that points to the right location in the
disassembly. Namely, 0x3000 + 0x26a5 = 0x56A5, and:
>
> ---
> $ objdump --headers --wide -S /usr/bin/ldmtool
>
> /usr/bin/ldmtool: file format elf64-x86-64
>
> Sections:
> Idx Name Size VMA LMA File off
> Algn Flags
> 0 .interp 0000001c 0000000000000318 0000000000000318 00000318
> 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA
> 1 .note.gnu.property 00000020 0000000000000338 0000000000000338 00000338
> 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA
> 2 .note.gnu.build-id 00000024 0000000000000358 0000000000000358 00000358
> 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA
> 3 .note.ABI-tag 00000020 000000000000037c 000000000000037c 0000037c
> 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA
> 4 .gnu.hash 00000040 00000000000003a0 00000000000003a0 000003a0
> 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA
> 5 .dynsym 000009d8 00000000000003e0 00000000000003e0 000003e0
> 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA
> 6 .dynstr 000007ef 0000000000000db8 0000000000000db8 00000db8
> 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA
> 7 .gnu.version 000000d2 00000000000015a8 00000000000015a8 000015a8
> 2**1 CONTENTS, ALLOC, LOAD, READONLY, DATA
> 8 .gnu.version_r 00000070 0000000000001680 0000000000001680 00001680
> 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA
> 9 .rela.dyn 00000228 00000000000016f0 00000000000016f0 000016f0
> 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA
> 10 .rela.plt 00000888 0000000000001918 0000000000001918 00001918
> 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA
> 11 .init 0000001b 0000000000003000 0000000000003000 00003000
> 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE
> 12 .plt 000005c0 0000000000003020 0000000000003020 00003020
> 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE
> 13 .plt.got 00000010 00000000000035e0 00000000000035e0 000035e0
> 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE
> 14 .plt.sec 000005b0 00000000000035f0 00000000000035f0 000035f0
> 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE
> 15 .text 00001c45 0000000000003ba0 0000000000003ba0 00003ba0
> 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE
> 16 .fini 0000000d 00000000000057e8 00000000000057e8 000057e8
> 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE
> 17 .rodata 0000064a 0000000000006000 0000000000006000 00006000
> 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA
> 18 .eh_frame_hdr 000000ec 000000000000664c 000000000000664c 0000664c
> 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA
> 19 .eh_frame 00000660 0000000000006738 0000000000006738 00006738
> 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA
> 20 .init_array 00000008 00000000000089b0 00000000000089b0 000079b0
> 2**3 CONTENTS, ALLOC, LOAD, DATA
> 21 .fini_array 00000008 00000000000089b8 00000000000089b8 000079b8
> 2**3 CONTENTS, ALLOC, LOAD, DATA
> 22 .data.rel.ro 000000b0 00000000000089c0 00000000000089c0 000079c0
> 2**5 CONTENTS, ALLOC, LOAD, DATA
> 23 .dynamic 00000260 0000000000008a70 0000000000008a70 00007a70
> 2**3 CONTENTS, ALLOC, LOAD, DATA
> 24 .got 00000328 0000000000008cd0 0000000000008cd0 00007cd0
> 2**3 CONTENTS, ALLOC, LOAD, DATA
> 25 .data 00000010 0000000000009000 0000000000009000 00008000
> 2**3 CONTENTS, ALLOC, LOAD, DATA
> 26 .bss 00000038 0000000000009020 0000000000009020 00008010
> 2**5 ALLOC
> 27 .gnu_debuglink 00000034 0000000000000000 0000000000000000 00008010
> 2**2 CONTENTS, READONLY
>
> [...]
>
> # ifdef __va_arg_pack
> __fortify_function int
> __NTH (asprintf (char **__restrict __ptr, const char *__restrict __fmt, ...))
> {
> return __asprintf_chk (__ptr, __USE_FORTIFY_LEVEL - 1, __fmt,
> 54ce: 48 89 e3 mov %rsp,%rbx
> 54d1: 48 89 c7 mov %rax,%rdi
> 54d4: 49 89 c5 mov %rax,%r13
> 54d7: e8 34 e5 ff ff callq 3a10 <g_array_set_clear_func@plt>
> 54dc: 48 89 ef mov %rbp,%rdi
> 54df: e8 7c e3 ff ff callq 3860 <readdir@plt>
> 54e4: 48 85 c0 test %rax,%rax
> 54e7: 74 65 je 554e
> <ldm_partition_get_name@plt+0x19be>
> 54e9: 4c 8d 60 13 lea 0x13(%rax),%r12
> 54ed: 48 8d 35 e3 10 00 00 lea 0x10e3(%rip),%rsi # 65d7
> <_IO_stdin_used@@Base+0x5d7>
> 54f4: 4c 89 e7 mov %r12,%rdi
> 54f7: e8 e4 e1 ff ff callq 36e0 <g_strcmp0@plt>
> 54fc: 85 c0 test %eax,%eax
> 54fe: 74 dc je 54dc
> <ldm_partition_get_name@plt+0x194c>
> 5500: 48 8d 35 cf 10 00 00 lea 0x10cf(%rip),%rsi # 65d6
> <_IO_stdin_used@@Base+0x5d6>
> 5507: 4c 89 e7 mov %r12,%rdi
> 550a: e8 d1 e1 ff ff callq 36e0 <g_strcmp0@plt>
> 550f: 85 c0 test %eax,%eax
> 5511: 74 c9 je 54dc
> <ldm_partition_get_name@plt+0x194c>
> 5513: 31 c0 xor %eax,%eax
> 5515: 4c 89 e1 mov %r12,%rcx
> 5518: 48 8d 15 ba 10 00 00 lea 0x10ba(%rip),%rdx # 65d9
> <_IO_stdin_used@@Base+0x5d9>
> 551f: 48 89 df mov %rbx,%rdi
> 5522: be 01 00 00 00 mov $0x1,%esi
> 5527: e8 e4 e2 ff ff callq 3810 <__asprintf_chk@plt>
> 552c: 83 f8 ff cmp $0xffffffff,%eax
> 552f: 74 43 je 5574
> <ldm_partition_get_name@plt+0x19e4>
> 5531: 4c 89 ef mov %r13,%rdi
> 5534: ba 01 00 00 00 mov $0x1,%edx
> 5539: 48 89 de mov %rbx,%rsi
> 553c: e8 0f e6 ff ff callq 3b50 <g_array_append_vals@plt>
> 5541: 48 89 ef mov %rbp,%rdi
> 5544: e8 17 e3 ff ff callq 3860 <readdir@plt>
> 5549: 48 85 c0 test %rax,%rax
> 554c: 75 9b jne 54e9
> <ldm_partition_get_name@plt+0x1959>
> 554e: 48 89 ef mov %rbp,%rdi
> 5551: e8 4a e5 ff ff callq 3aa0 <closedir@plt>
> 5556: 48 8b 44 24 08 mov 0x8(%rsp),%rax
> 555b: 64 48 33 04 25 28 00 00 00 xor %fs:0x28,%rax
> 5564: 75 44 jne 55aa
> <ldm_partition_get_name@plt+0x1a1a>
> 5566: 48 83 c4 18 add $0x18,%rsp
> 556a: 4c 89 e8 mov %r13,%rax
> 556d: 5b pop %rbx
> 556e: 5d pop %rbp
> 556f: 41 5c pop %r12
> 5571: 41 5d pop %r13
> 5573: c3 retq
> 5574: 48 8d 15 66 10 00 00 lea 0x1066(%rip),%rdx # 65e1
> <_IO_stdin_used@@Base+0x5e1>
> 557b: be 04 00 00 00 mov $0x4,%esi
> 5580: 31 ff xor %edi,%edi
> 5582: 31 c0 xor %eax,%eax
> 5584: e8 d7 e5 ff ff callq 3b60 <g_log@plt>
> 5589: eb fe jmp 5589
> <ldm_partition_get_name@plt+0x19f9>
> 558b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> 5590: 48 8d 15 21 10 00 00 lea 0x1021(%rip),%rdx # 65b8
> <_IO_stdin_used@@Base+0x5b8>
> 5597: be 10 00 00 00 mov $0x10,%esi
> 559c: 31 ff xor %edi,%edi
> 559e: 31 c0 xor %eax,%eax
> 55a0: e8 bb e5 ff ff callq 3b60 <g_log@plt>
> 55a5: 45 31 ed xor %r13d,%r13d
> 55a8: eb ac jmp 5556
> <ldm_partition_get_name@plt+0x19c6>
> 55aa: e8 21 e4 ff ff callq 39d0 <__stack_chk_fail@plt>
> 55af: 90 nop
> 55b0: f3 0f 1e fa endbr64
> 55b4: 41 57 push %r15
> 55b6: 49 89 d7 mov %rdx,%r15
> 55b9: 41 56 push %r14
> 55bb: 49 89 ce mov %rcx,%r14
> 55be: 41 55 push %r13
> 55c0: 45 89 c5 mov %r8d,%r13d
> 55c3: 41 54 push %r12
> 55c5: 55 push %rbp
> 55c6: 48 89 fd mov %rdi,%rbp
> 55c9: 53 push %rbx
> 55ca: 4c 89 cb mov %r9,%rbx
> 55cd: 48 83 ec 28 sub $0x28,%rsp
> 55d1: 64 48 8b 04 25 28 00 00 00 mov %fs:0x28,%rax
> 55da: 48 89 44 24 18 mov %rax,0x18(%rsp)
> 55df: 31 c0 xor %eax,%eax
> 55e1: 48 85 f6 test %rsi,%rsi
> 55e4: 0f 84 b6 00 00 00 je 56a0
> <ldm_partition_get_name@plt+0x1b10>
> 55ea: 48 89 f7 mov %rsi,%rdi
> 55ed: 49 89 f4 mov %rsi,%r12
> 55f0: e8 cb e1 ff ff callq 37c0 <g_strv_length@plt>
> 55f5: 45 31 c0 xor %r8d,%r8d
> 55f8: 4c 89 e1 mov %r12,%rcx
> 55fb: be 01 00 00 00 mov $0x1,%esi
> 5600: 89 c2 mov %eax,%edx
> 5602: 48 89 ef mov %rbp,%rdi
> 5605: e8 c6 ea ff ff callq 40d0
> <ldm_partition_get_name@plt+0x540>
> 560a: 85 c0 test %eax,%eax
> 560c: 74 67 je 5675
> <ldm_partition_get_name@plt+0x1ae5>
> 560e: e8 5d e4 ff ff callq 3a70 <json_builder_new@plt>
> 5613: 48 8d 4c 24 14 lea 0x14(%rsp),%rcx
> 5618: 48 89 da mov %rbx,%rdx
> 561b: 4d 89 f9 mov %r15,%r9
> 561e: 48 83 ec 08 sub $0x8,%rsp
> 5622: 4d 89 f0 mov %r14,%r8
> 5625: 44 89 ee mov %r13d,%esi
> 5628: 48 89 ef mov %rbp,%rdi
> 562b: 50 push %rax
> 562c: 49 89 c4 mov %rax,%r12
> 562f: e8 2c e9 ff ff callq 3f60
> <ldm_partition_get_name@plt+0x3d0>
> 5634: 5a pop %rdx
> 5635: 59 pop %rcx
> 5636: 85 c0 test %eax,%eax
> 5638: 74 16 je 5650
> <ldm_partition_get_name@plt+0x1ac0>
> 563a: 4c 89 e7 mov %r12,%rdi
> 563d: e8 8e e0 ff ff callq 36d0 <g_object_unref@plt>
> 5642: 8b 44 24 14 mov 0x14(%rsp),%eax
> 5646: eb 2f jmp 5677
> <ldm_partition_get_name@plt+0x1ae7>
> 5648: 0f 1f 84 00 00 00 00 00 nopl 0x0(%rax,%rax,1)
> 5650: 48 8b 0b mov (%rbx),%rcx
> 5653: 48 8d 15 a2 0f 00 00 lea 0xfa2(%rip),%rdx # 65fc
> <_IO_stdin_used@@Base+0x5fc>
> 565a: 31 ff xor %edi,%edi
> 565c: 31 c0 xor %eax,%eax
> 565e: be 10 00 00 00 mov $0x10,%esi
> 5663: e8 f8 e4 ff ff callq 3b60 <g_log@plt>
> 5668: 4d 85 e4 test %r12,%r12
> 566b: 74 08 je 5675
> <ldm_partition_get_name@plt+0x1ae5>
> 566d: 4c 89 e7 mov %r12,%rdi
> 5670: e8 5b e0 ff ff callq 36d0 <g_object_unref@plt>
> 5675: 31 c0 xor %eax,%eax
> 5677: 48 8b 5c 24 18 mov 0x18(%rsp),%rbx
> 567c: 64 48 33 1c 25 28 00 00 00 xor %fs:0x28,%rbx
> 5685: 75 5e jne 56e5
> <ldm_partition_get_name@plt+0x1b55>
> 5687: 48 83 c4 28 add $0x28,%rsp
> 568b: 5b pop %rbx
> 568c: 5d pop %rbp
> 568d: 41 5c pop %r12
> 568f: 41 5d pop %r13
> 5691: 41 5e pop %r14
> 5693: 41 5f pop %r15
> 5695: c3 retq
> 5696: 66 2e 0f 1f 84 00 00 00 00 00 nopw %cs:0x0(%rax,%rax,1)
> 56a0: e8 db fd ff ff callq 5480
> <ldm_partition_get_name@plt+0x18f0>
> 56a5: 4c 8b 20 mov (%rax),%r12
this is where we crash.
Laszlo
> 56a8: 48 89 44 24 08 mov %rax,0x8(%rsp)
> 56ad: 4c 89 e7 mov %r12,%rdi
> 56b0: e8 0b e1 ff ff callq 37c0 <g_strv_length@plt>
> 56b5: 45 31 c0 xor %r8d,%r8d
> 56b8: 4c 89 e1 mov %r12,%rcx
> 56bb: be 01 00 00 00 mov $0x1,%esi
> 56c0: 89 c2 mov %eax,%edx
> 56c2: 48 89 ef mov %rbp,%rdi
> 56c5: e8 06 ea ff ff callq 40d0
> <ldm_partition_get_name@plt+0x540>
> 56ca: 4c 8b 54 24 08 mov 0x8(%rsp),%r10
> 56cf: 85 c0 test %eax,%eax
> 56d1: 75 17 jne 56ea
> <ldm_partition_get_name@plt+0x1b5a>
> 56d3: 4c 89 d7 mov %r10,%rdi
> 56d6: 89 44 24 08 mov %eax,0x8(%rsp)
> 56da: e8 81 e0 ff ff callq 3760 <g_array_unref@plt>
> 56df: 8b 44 24 08 mov 0x8(%rsp),%eax
> 56e3: eb 92 jmp 5677
> <ldm_partition_get_name@plt+0x1ae7>
> 56e5: e8 e6 e2 ff ff callq 39d0 <__stack_chk_fail@plt>
> 56ea: 4c 89 54 24 08 mov %r10,0x8(%rsp)
> 56ef: e8 7c e3 ff ff callq 3a70 <json_builder_new@plt>
> 56f4: 48 8d 4c 24 14 lea 0x14(%rsp),%rcx
> 56f9: 4d 89 f0 mov %r14,%r8
> 56fc: 48 89 ef mov %rbp,%rdi
> 56ff: 56 push %rsi
> 5700: 4d 89 f9 mov %r15,%r9
> 5703: 48 89 da mov %rbx,%rdx
> 5706: 44 89 ee mov %r13d,%esi
> 5709: 50 push %rax
> 570a: 49 89 c4 mov %rax,%r12
> 570d: e8 4e e8 ff ff callq 3f60
> <ldm_partition_get_name@plt+0x3d0>
> 5712: 5f pop %rdi
> 5713: 41 58 pop %r8
> 5715: 85 c0 test %eax,%eax
> 5717: 4c 8b 54 24 08 mov 0x8(%rsp),%r10
> 571c: 74 19 je 5737
> <ldm_partition_get_name@plt+0x1ba7>
> 571e: 4c 89 d7 mov %r10,%rdi
> 5721: e8 3a e0 ff ff callq 3760 <g_array_unref@plt>
> 5726: 4c 89 e7 mov %r12,%rdi
> 5729: e8 a2 df ff ff callq 36d0 <g_object_unref@plt>
> 572e: 8b 44 24 14 mov 0x14(%rsp),%eax
> 5732: e9 40 ff ff ff jmpq 5677
> <ldm_partition_get_name@plt+0x1ae7>
> 5737: 48 8b 0b mov (%rbx),%rcx
> 573a: 31 ff xor %edi,%edi
> 573c: 48 8d 15 b9 0e 00 00 lea 0xeb9(%rip),%rdx # 65fc
> <_IO_stdin_used@@Base+0x5fc>
> 5743: 31 c0 xor %eax,%eax
> 5745: be 10 00 00 00 mov $0x10,%esi
> 574a: 4c 89 54 24 08 mov %r10,0x8(%rsp)
> 574f: e8 0c e4 ff ff callq 3b60 <g_log@plt>
> 5754: 4c 8b 54 24 08 mov 0x8(%rsp),%r10
> 5759: 4c 89 d7 mov %r10,%rdi
> 575c: e8 ff df ff ff callq 3760 <g_array_unref@plt>
> 5761: e9 02 ff ff ff jmpq 5668
> <ldm_partition_get_name@plt+0x1ad8>
> 5766: 66 2e 0f 1f 84 00 00 00 00 00 nopw %cs:0x0(%rax,%rax,1)
> 5770: f3 0f 1e fa endbr64
> 5774: 41 57 push %r15
> 5776: 4c 8d 3d 33 32 00 00 lea 0x3233(%rip),%r15 # 89b0
> <_IO_stdin_used@@Base+0x29b0>
> 577d: 41 56 push %r14
> 577f: 49 89 d6 mov %rdx,%r14
> 5782: 41 55 push %r13
> 5784: 49 89 f5 mov %rsi,%r13
> 5787: 41 54 push %r12
> 5789: 41 89 fc mov %edi,%r12d
> 578c: 55 push %rbp
> 578d: 48 8d 2d 24 32 00 00 lea 0x3224(%rip),%rbp # 89b8
> <_IO_stdin_used@@Base+0x29b8>
> 5794: 53 push %rbx
> 5795: 4c 29 fd sub %r15,%rbp
> 5798: 48 83 ec 08 sub $0x8,%rsp
> 579c: e8 5f d8 ff ff callq 3000 <__cxa_finalize@plt-0x5e0>
> 57a1: 48 c1 fd 03 sar $0x3,%rbp
> 57a5: 74 1f je 57c6
> <ldm_partition_get_name@plt+0x1c36>
> 57a7: 31 db xor %ebx,%ebx
> 57a9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
> 57b0: 4c 89 f2 mov %r14,%rdx
> 57b3: 4c 89 ee mov %r13,%rsi
> 57b6: 44 89 e7 mov %r12d,%edi
> 57b9: 41 ff 14 df callq *(%r15,%rbx,8)
> 57bd: 48 83 c3 01 add $0x1,%rbx
> 57c1: 48 39 dd cmp %rbx,%rbp
> 57c4: 75 ea jne 57b0
> <ldm_partition_get_name@plt+0x1c20>
> 57c6: 48 83 c4 08 add $0x8,%rsp
> 57ca: 5b pop %rbx
> 57cb: 5d pop %rbp
> 57cc: 41 5c pop %r12
> 57ce: 41 5d pop %r13
> 57d0: 41 5e pop %r14
> 57d2: 41 5f pop %r15
> 57d4: c3 retq
> 57d5: 66 66 2e 0f 1f 84 00 00 00 00 00 data16 nopw
> %cs:0x0(%rax,%rax,1)
> 57e0: f3 0f 1e fa endbr64
> 57e4: c3 retq
>
> Disassembly of section .fini:
>
> 00000000000057e8 <.fini>:
> 57e8: f3 0f 1e fa endbr64
> 57ec: 48 83 ec 08 sub $0x8,%rsp
> 57f0: 48 83 c4 08 add $0x8,%rsp
> 57f4: c3
>
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs
