qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: QEMU function trace


From: Claudio Fontana
Subject: Re: QEMU function trace
Date: Wed, 14 Dec 2022 13:35:58 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0

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..

Ciao,

Claudio



reply via email to

[Prev in Thread] Current Thread [Next in Thread]