Thanks very much.
According to your reply, I reviewd qemu loader and plugins source code again, I think I've got what you mentioned.
In qemu linux-user(user mode) case, the guest images are all ELF format, and inside the ELF loader qemu will call load_symbols function, so in this case, the symbol table is loaded while loading ELF automatically, we don't need extra effort to load symbol table.
But for kernel booting case, the guest image format we use in -kernel option is Image but not ELF, and there is no load_symbols behavior during the loading process, so plugins can't see the kernel symbol.
What we probably need to do is adding symbol loading behavior in kernel loader and populating syminfos to plugins, or writing a System.map parser in self-defined plugin as you said, maybe the later is a faster way.
BTW, sorry for the auto-reply, it has been turned-off, thanks for the heads up.
Thanks.
On 2022-12-14 23:03:38，"Alex Bennée" <alex.bennee@linaro.org> wrote:
>
>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