Re: QEMU function trace

[Alex Bennée]

Claudio Fontana <cfontana@suse.de> writes:

> On 12/14/22 12:00, Alex Bennée wrote:
>> 
>> Alex Bennée <alex.bennee@linaro.org> writes:
>> 
>>> wanghw364  <wanghw364@163.com> writes:
>>>
>>>> Thanks. I have several questions as below, please help, thanks.
>>>>
>>>> 1.What do you mean by "only have debug symbols available for
>>>> linux-user so"? What does the linux-user so
>>>> refer to?
>>>>  qemu_plugin_insn_symbol() can only see symbols from linux-user so?
>>>
>>> The linux-user ELF loader will read the debug symbols (if they exist)
>>> and populate the syminfos structures that lookup_symbol uses. It's
>>> partially obscured by the ELF loaders heavy use of macros but see:
>>>
>>>   static void glue(load_symbols, SZ)(struct elfhdr *ehdr, int fd, int 
>>> must_swab,
>>>                                      int clear_lsb, symbol_fn_t sym_cb)
>>>
>>> in elf_ops.h
>>>
>>>> 2.The purpose of teaching the linux kernel loader to understand and 
>>>> relocate symbols from an ELF kernel
>>>> image,
>>>> or extract then and feed them directly to the plugin, is to solve
>>>> the issue that qemu_plugin_insn_symbol()
>>>> can't see kernel symbol?
>>>
>>> Yes. This is slightly complicated by the fact that the kernel loaders don't
>>> expect to load pure ELF files but something that is wrapped up as a
>>> Linux loader. For example:
>>>
>>>   ➜  file vmlinux
>>>   vmlinux: ELF 64-bit LSB pie executable, ARM aarch64, version 1
>>> (SYSV), statically linked,
>>> BuildID[sha1]=21166458a10404e6157abf0da4a0921144c72675, with
>>> debug_info, not stripped
>>>   🕙10:07:42 alex@zen:linux.git/builds/arm64.initramfs with
>>> arm64/aarch64-linux-gnu- on  linux-6.0.y [$!?]
>>>   ➜  file arch/arm64/boot/Image
>>>   arch/arm64/boot/Image: Linux kernel ARM64 boot executable Image, 
>>> little-endian, 4K pages
>>>
>>> The second file is what is actually passed to -kernel in a typical boot.
>>>
>>> The logic in arm_setup_direct_kernel_boot() implies you can load ELFs
>>> directly and boot them but for some reason the Linux kernel doesn't work
>>> if you try this way.
>> 
>> Replying to myself - this is because the vmlinux image is based of
>> kernel virtual address. So the import thing the loader does is create
>> the initial vaddr mappings and relocate the kernel to that location
>> before running it. See the function primary_entry in head.S in the
>> kernel.
>> 
>> So perhaps for system emulation it would be useful to have a -symbols
>> option to load symbols from another file.
>> 
>
> Hi Alex,
>
> it doesn't need to be a tcg plugin-only feature right, it's possible
> to use qemu to debug the guest also when using KVM..

No it doesn't have to be although the only real users is the -d in_asm
trace which I suspect doesn't get used as much for system emulation
given the size of the traces.

For normal debugging over the gdbstub its usually left up to the gdb
process itself to handle the resolution of symbols, e.g.:

  gdb vmlinux -ex "target remote localhost:1234"

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro