2:35 a.m.
Hi
I use crash8.0.4_arm64 to parse the ramdump of android15-k6.6, load the symbol of ko,
and disassemble the functions in ko through the "dis -lx" command.
I can get the assembly instructions, but I cannot get the corresponding assembly
instructions. lines of source code.
The following error is reported when using the command
GNU_RESOLVE_TEXT_ADDR: returned via gdb_error_hook (1 buffer in use)
GNU_GET_FUNCTION_RANGE: returned via gdb_error_hook (1 buffer in use
I use the disassembly tool that comes with Android, such as objdump, to disassemble ko.
I can see the code lines corresponding to the functions in ko..
So, is this a problem with the gdb tool or is there something wrong with my ko symbol?
Thanks a lot.
________________________________
This email (including its attachments) is intended only for the person or entity to which
it is addressed and may contain information that is privileged, confidential or otherwise
protected from disclosure. Unauthorized use, dissemination, distribution or copying of
this email or the information herein or taking any action in reliance on the contents of
this email or the information herein, by anyone other than the intended recipient, or an
employee or agent responsible for delivering the message to the intended recipient, is
strictly prohibited. If you are not the intended recipient, please do not read, copy, use
or disclose any part of this e-mail to others. Please notify the sender immediately and
permanently delete this e-mail and any attachments if you received it in error. Internet
communications cannot be guaranteed to be timely, secure, error-free or virus-free. The
sender does not accept liability for any errors or omissions.
本邮件及其附件具有保密性质，受法律保护不得泄露，仅发送给本邮件所指特定收件人。严禁非经授权使用、宣传、发布或复制本邮件或其内容。若非该特定收件人，请勿阅读、复制、
使用或披露本邮件的任何内容。若误收本邮件，请从系统中永久性删除本邮件及所有附件，并以回复邮件的方式即刻告知发件人。无法保证互联网通信及时、安全、无误或防毒。发件人对任何错漏均不承担责任。
12:02 a.m.
New subject: crash8.0.4 cannot get source line nums of functions from ko on android15-k6.6
On 2024/01/30 17:08, 王天明 (Tianming Wang) wrote:
Hi
I use crash8.0.4_arm64 to parse the ramdump of android15-k6.6, load the symbol of ko,
and disassemble the functions in ko through the "dis -lx" command.
I can get the assembly instructions, but I cannot get the corresponding assembly
instructions. lines of source code.
The following error is reported when using the command
GNU_RESOLVE_TEXT_ADDR: returned via gdb_error_hook (1 buffer in use)
GNU_GET_FUNCTION_RANGE: returned via gdb_error_hook (1 buffer in use
hmm, I've not seen this kind of errors with the "dis -l".
It looks like the former cannot find the function or it's not a function:
case GNU_RESOLVE_TEXT_ADDR:
sym = find_pc_function(req->addr);
if (!sym || TYPE_CODE(sym->type) != TYPE_CODE_FUNC)
req->flags |= GNU_COMMAND_FAILED;
break;
what do you see with these after loading the module?
crash> sym <function name>
crash> whatis <function name>
crash> gdb info line <function name>
Thanks,
Kazu
12:43 a.m.
New subject: crash8.0.4 cannot get source line nums of functions from ko on android15-k6.6
Hi kazu
it looks ok（I added xxx myself for safety）
crash_arm64_v8.0.4++> sym sysdump_panic_event
ffffffxxxxx384 (t) sysdump_panic_event [xxx]
crash_arm64_v8.0.4++> whatis sysdump_panic_event
int sysdump_panic_event(struct notifier_block *, unsigned long, void *);
crash_arm64_v8.0.4++> gdb info line sysdump_panic_event
Line 759 of "drivers/xxxx.c" starts at address 0x4a74 and ends at 0x4a9c.
crash_arm64_v8.0.4++>
12:56 a.m.
New subject: crash8.0.4 cannot get source line nums of functions from ko on android15-k6.6
On 2024/02/05 15:43, tianming.wang(a)unisoc.com wrote:
Hi kazu
it looks ok（I added xxx myself for safety）
crash_arm64_v8.0.4++> sym sysdump_panic_event
ffffffxxxxx384 (t) sysdump_panic_event [xxx]
crash_arm64_v8.0.4++> whatis sysdump_panic_event
int sysdump_panic_event(struct notifier_block *, unsigned long, void *);
crash_arm64_v8.0.4++> gdb info line sysdump_panic_event
Line 759 of "drivers/xxxx.c" starts at address 0x4a74 and ends at 0x4a9c.
crash_arm64_v8.0.4++>
hmm, does "dis -l sysdump_panic_event" emit errors after this?
Thanks,
Kazu
1:20 a.m.
New subject: crash8.0.4 cannot get source line nums of functions from ko on android15-k6.6
After raising the loglevel to 7, enter ” whatis sysdump_panic_event“ and an error will be
reported.
crash_arm64_v8.0.4++> sym sysdump_panic_event
ffffffxxxx384 (t) sysdump_panic_event [xxxx]
crash_arm64_v8.0.4++> whatis sysdump_panic_event
GNU_PASS_THROUGH: returned via gdb_error_hook (1 buffer in use)
whatis: gdb request failed: whatis sysdump_panic_event
crash_arm64_v8.0.4++> gdb info line sysdump_panic_event
GNU_PASS_THROUGH: returned via gdb_error_hook (1 buffer in use)
gdb: gdb request failed: info line sysdump_panic_event
crash_arm64_v8.0.4++> dis -l sysdump_panic_event
GNU_RESOLVE_TEXT_ADDR: returned via gdb_error_hook (1 buffer in use)
GNU_GET_FUNCTION_RANGE: returned via gdb_error_hook (1 buffer in use)
0xffffffxxx <sysdump_panic_event>: <readmem: ffffffc07b0aa380, KVADDR,
"gdb_readmem_callback", 64, (ROE), 55579b55293c>
0xffffffxxx <sysdump_panic_event>: addr: ffffffc07b0aa380 paddr: 10286c380 cnt:
64>
mov x9, x30
0xffffffxxx <sysdump_panic_event+4>: nop
0xffffffxxx <sysdump_panic_event+8>: str x30, [x18], #8
0xffffffxxx <sysdump_panic_event+12>: sub sp, sp, #0xa0
0xffffffxxx <sysdump_panic_event+16>: stp x29, x30, [sp, #96]
0xffffffxxx <sysdump_panic_event+20>: stp x24, x23, [sp, #112]
0xffffffxxx <sysdump_panic_event+24>: stp x22, x21, [sp, #128]
When using the default loglevel, no error will be reported, but the number of source code
lines cannot be seen.
crash_arm64_v8.0.4++> sym sysdump_panic_event
ffffffxxxx84 (t) sysdump_panic_event [xxxx]
crash_arm64_v8.0.4++> whatis sysdump_panic_event
int sysdump_panic_event(struct notifier_block *, unsigned long, void *);
crash_arm64_v8.0.4++> gdb info line sysdump_panic_event
Line 759 of "drivers/xxxx.c" starts at address 0x4a74 and ends at 0x4a9c.
crash_arm64_v8.0.4++> dis -l sysdump_panic_event
0xffffffxxx <sysdump_panic_event>: mov x9, x30
0xffffffxxx <sysdump_panic_event+4>: nop
0xffffffxxx <sysdump_panic_event+8>: str x30, [x18], #8
0xffffffxxx <sysdump_panic_event+12>: sub sp, sp, #0xa0
0xffffffxxx <sysdump_panic_event+16>: stp x29, x30, [sp, #96]
0xffffffxxx <sysdump_panic_event+20>: stp x24, x23, [sp, #112]
0xffffffxxx <sysdump_panic_event+24>: stp x22, x21, [sp, #128]
0xffffffxxx <sysdump_panic_event+28>: stp x20, x19, [sp, #144]
0xffffffxxx <sysdump_panic_event+32>: add x29, sp, #0x60
0xffffffxxx <sysdump_panic_event+36>: mrs x8, sp_el0
0xffffffxxx <sysdump_panic_event+40>: adrp x21, 0xffffffc0822d8000
<__per_cpu_load>
0xffffffxxx <sysdump_panic_event+44>: add x21, x21, #0x8
0xffffffxxx <sysdump_panic_event+48>: ldr x8, [x8, #1440]
1:57 a.m.
New subject: crash8.0.4 cannot get source line nums of functions from ko on android15-k6.6
On 2024/02/05 16:20, tianming.wang(a)unisoc.com wrote:
After raising the loglevel to 7, enter ” whatis sysdump_panic_event“ and an error will be
reported.
crash_arm64_v8.0.4++> sym sysdump_panic_event
ffffffxxxx384 (t) sysdump_panic_event [xxxx]
crash_arm64_v8.0.4++> whatis sysdump_panic_event
GNU_PASS_THROUGH: returned via gdb_error_hook (1 buffer in use)
whatis: gdb request failed: whatis sysdump_panic_event
crash_arm64_v8.0.4++> gdb info line sysdump_panic_event
GNU_PASS_THROUGH: returned via gdb_error_hook (1 buffer in use)
gdb: gdb request failed: info line sysdump_panic_event
crash_arm64_v8.0.4++> dis -l sysdump_panic_event
GNU_RESOLVE_TEXT_ADDR: returned via gdb_error_hook (1 buffer in use)
GNU_GET_FUNCTION_RANGE: returned via gdb_error_hook (1 buffer in use)
0xffffffxxx <sysdump_panic_event>: <readmem: ffffffc07b0aa380, KVADDR,
"gdb_readmem_callback", 64, (ROE), 55579b55293c>
0xffffffxxx <sysdump_panic_event>: addr: ffffffc07b0aa380 paddr: 10286c380 cnt:
64>
mov x9, x30
0xffffffxxx <sysdump_panic_event+4>: nop
0xffffffxxx <sysdump_panic_event+8>: str x30, [x18], #8
0xffffffxxx <sysdump_panic_event+12>: sub sp, sp, #0xa0
0xffffffxxx <sysdump_panic_event+16>: stp x29, x30, [sp, #96]
0xffffffxxx <sysdump_panic_event+20>: stp x24, x23, [sp, #112]
0xffffffxxx <sysdump_panic_event+24>: stp x22, x21, [sp, #128]
higher debug level occasionally breaks the behavior of commands..
When using the default loglevel, no error will be reported, but the number of source code
lines cannot be seen.
crash_arm64_v8.0.4++> sym sysdump_panic_event
ffffffxxxx84 (t) sysdump_panic_event [xxxx]
crash_arm64_v8.0.4++> whatis sysdump_panic_event
int sysdump_panic_event(struct notifier_block *, unsigned long, void *);
crash_arm64_v8.0.4++> gdb info line sysdump_panic_event
Line 759 of "drivers/xxxx.c" starts at address 0x4a74 and ends at 0x4a9c.
Thanks for the info.
hmm, the section mapping in gdb looks wrong..
What is printed with these?
crash> set debug 1
crash> mod -s xxx
crash> gdb info address sysdump_panic_event
crash> gdb info symbol sysdump_panic_event
2:20 a.m.
New subject: crash8.0.4 cannot get source line nums of functions from ko on android15-k6.6
crash_arm64_v8.0.4++> set debug 1
debug: 1
crash_arm64_v8.0.4++> mod -s sysdump
sysdump: module symbols are already loaded
MODULE NAME TEXT_BASE SIZE OBJECT FILE
ffffffxxxx sysdump ffffffxxx 110592
/home/tianming.wang/k66/sysdump.ko
crash_arm64_v8.0.4++> gdb info address sysdump_panic_event
Symbol "sysdump_panic_event" is a function at address 0x4a74.
crash_arm64_v8.0.4++> gdb info symbol sysdump_panic_event
sysdump_panic_event in section .text.sysdump_panic_event of
/home/tianming.wang/k66/sysdump.ko
crash_arm64_v8.0.4++>
11:03 p.m.
New subject: crash8.0.4 cannot get source line nums of functions from ko on android15-k6.6
On 2024/02/05 17:20, tianming.wang(a)unisoc.com wrote:
crash_arm64_v8.0.4++> set debug 1
debug: 1
crash_arm64_v8.0.4++> mod -s sysdump
sysdump: module symbols are already loaded
then please delete it first.
crash> mod -d sysdump
crash> set debug 1
crash> mod -s sysdump
Thanks,
Kazu
> MODULE NAME TEXT_BASE SIZE OBJECT
FILE
> ffffffxxxx sysdump ffffffxxx 110592
/home/tianming.wang/k66/sysdump.ko
> crash_arm64_v8.0.4++> gdb info address sysdump_panic_event
> Symbol "sysdump_panic_event" is a function at address 0x4a74.
> crash_arm64_v8.0.4++> gdb info symbol sysdump_panic_event
> sysdump_panic_event in section .text.sysdump_panic_event of
/home/tianming.wang/k66/sysdump.ko
8:13 p.m.
New subject: crash8.0.4 cannot get source line nums of functions from ko on android15-k6.6
Hi kazu
I delete it first,
Info as follows
crash_arm64_v8.0.4++> mod -d sysdump
crash_arm64_v8.0.4++> set debug 1
debug: 1
crash_arm64_v8.0.4++> mod -s sysdump
mod: WARNING: module section data structures unrecognized or changed
add-symbol-file /home/tianming.wang/k66/sysdump.ko 0xffffffxxx -s .data 0xffffffxxx -s
.bss 0xffffffxxx -s .rodata 0xffffffxxx
add symbol table from file "/home/tianming.wang/k66/sysdump.ko" at
.text_addr = 0xffffffxxx
.data_addr = 0xffffffxxx
.bss_addr = 0xffffffxxx
.rodata_addr = 0xffffffxxx
MODULE NAME TEXT_BASE SIZE OBJECT FILE
ffffffxxx sysdump ffffffxxx 110592
/home/tianming.wang/k66/sysdump.ko
crash_arm64_v8.0.4++> gdb info address sysdump_panic_event
Symbol "sysdump_panic_event" is a function at address 0x4a74.
crash_arm64_v8.0.4++> gdb info symbol sysdump_panic_event
sysdump_panic_event in section .text.sysdump_panic_event of
/home/tianming.wang/k66/sysdump.ko
crash_arm64_v8.0.4++> mod -s sysdump
sysdump: module symbols are already loaded
MODULE NAME TEXT_BASE SIZE OBJECT FILE
ffffffxxx sysdump ffffffxxx 110592
/home/tianming.wang/k66/sysdump.ko
Thanks
2:21 a.m.
New subject: crash8.0.4 cannot get source line nums of functions from ko on android15-k6.6
On 2024/02/19 11:13, tianming.wang(a)unisoc.com wrote:
Hi kazu
I delete it first,
Info as follows
crash_arm64_v8.0.4++> mod -d sysdump
crash_arm64_v8.0.4++> set debug 1
debug: 1
crash_arm64_v8.0.4++> mod -s sysdump
mod: WARNING: module section data structures unrecognized or changed
Thanks for the info.
It looks like module section data cannot be read and its fallback
routine also doesn't work enough to read the specific section except for
the major sections.
What happens with the attached patch?
If still broken, could I have this again?
crash> mod -d sysdump
crash> set debug 1
crash> mod -s sysdump
Thanks,
Kazu
add-symbol-file /home/tianming.wang/k66/sysdump.ko 0xffffffxxx -s
.data 0xffffffxxx -s .bss 0xffffffxxx -s .rodata 0xffffffxxx
add symbol table from file "/home/tianming.wang/k66/sysdump.ko" at
.text_addr = 0xffffffxxx
.data_addr = 0xffffffxxx
.bss_addr = 0xffffffxxx
.rodata_addr = 0xffffffxxx
MODULE NAME TEXT_BASE SIZE OBJECT FILE
ffffffxxx sysdump ffffffxxx 110592
/home/tianming.wang/k66/sysdump.ko
crash_arm64_v8.0.4++> gdb info address sysdump_panic_event
Symbol "sysdump_panic_event" is a function at address 0x4a74.
crash_arm64_v8.0.4++> gdb info symbol sysdump_panic_event
sysdump_panic_event in section .text.sysdump_panic_event of
/home/tianming.wang/k66/sysdump.ko
crash_arm64_v8.0.4++> mod -s sysdump
sysdump: module symbols are already loaded
MODULE NAME TEXT_BASE SIZE OBJECT FILE
ffffffxxx sysdump ffffffxxx 110592
/home/tianming.wang/k66/sysdump.ko
Thanks
--
Crash-utility mailing list -- devel(a)lists.crash-utility.osci.io
To unsubscribe send an email to devel-leave(a)lists.crash-utility.osci.io
https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/
Contribution Guidelines: https://github.com/crash-utility/crash/wiki
7:45 p.m.
New subject: crash8.0.4 cannot get source line nums of functions from ko on android15-k6.6
Hi kazu
After Iapply this patch, it is still broken.
Here are some errors.
crash_latest_fix_k66> mod -d sysdump
crash_latest_fix_k66> set debug 1
debug: 1
crash_latest_fix_k66> mod -s sysdump
ffffffxxx__ksymtab
ffffffxxx __kcrctab
ffffffxxx .altinstructions
ffffffxxx __bug_table
ffffffxxx __jump_table
ffffffxxx .bss
ffffffxxx .data
ffffffxxx.rodata
..............
.............
ffffffxxx .note.gnu.build-id
ffffffxxx .note.gnu.property
ffffffxxx.symtab
ffffffxxx .strtab
/home/tianming.wang/workdir/kernel_6.6/sysdump.ko: add_symbol_file_kallsyms failed
add-symbol-file /home/tianming.wang/workdir/kernel_6.6/sysdump.ko 0xffffffxxx -s .data
0xffffffxxx-s .bss 0xffffffxxx -s .rodata 0xffffffxxx
add symbol table from file "/home/tianming.wang/workdir/kernel_6.6/sysdump.ko"
at
.text_addr = 0xffffffxxx
.data_addr = 0xffffffxxx
.bss_addr = 0xffffffxxx
.rodata_addr = 0xffffffxxx
MODULE NAME TEXT_BASE SIZE OBJECT FILE
0xffffffxxx sysdump 0xffffffxxx 106496
/home/tianming.wang/workdir/kernel_6.6/sysdump.ko
9:07 p.m.
New subject: crash8.0.4 cannot get source line nums of functions from ko on android15-k6.6
On 2024/03/01 10:45, tianming.wang(a)unisoc.com wrote:
Hi kazu
After Iapply this patch, it is still broken.
Here are some errors.
crash_latest_fix_k66> mod -d sysdump
crash_latest_fix_k66> set debug 1
debug: 1
crash_latest_fix_k66> mod -s sysdump
ffffffxxx__ksymtab
ffffffxxx __kcrctab
ffffffxxx .altinstructions
ffffffxxx __bug_table
ffffffxxx __jump_table
ffffffxxx .bss
ffffffxxx .data
ffffffxxx.rodata
..............
.............
ffffffxxx .note.gnu.build-id
ffffffxxx .note.gnu.property
ffffffxxx.symtab
ffffffxxx .strtab
/home/tianming.wang/workdir/kernel_6.6/sysdump.ko: add_symbol_file_kallsyms failed
Thanks for trying. Hmm, it can work well with a 6.6 dump on hand..
btw, does ".text" section exist in the section list above? It seems
that it's necessary for add_symbol_file_kallsyms() succeeds.
if (STREQ(section_name, ".text")) {
...
retval = TRUE;
Kazu
> add-symbol-file /home/tianming.wang/workdir/kernel_6.6/sysdump.ko 0xffffffxxx -s
.data 0xffffffxxx-s .bss 0xffffffxxx -s .rodata 0xffffffxxx
> add symbol table from file
"/home/tianming.wang/workdir/kernel_6.6/sysdump.ko" at
> .text_addr = 0xffffffxxx
> .data_addr = 0xffffffxxx
> .bss_addr = 0xffffffxxx
> .rodata_addr = 0xffffffxxx
> MODULE NAME TEXT_BASE SIZE OBJECT
FILE
> 0xffffffxxx sysdump 0xffffffxxx 106496
/home/tianming.wang/workdir/kernel_6.6/sysdump.ko
> --
> Crash-utility mailing list -- devel(a)lists.crash-utility.osci.io
> To unsubscribe send an email to devel-leave(a)lists.crash-utility.osci.io
> https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/
> Contribution Guidelines: https://github.com/crash-utility/crash/wiki
9:17 p.m.
New subject: crash8.0.4 cannot get source line nums of functions from ko on android15-k6.6
On 2024/03/01 12:07, HAGIO KAZUHITO(萩尾 一仁) wrote:
On 2024/03/01 10:45, tianming.wang(a)unisoc.com wrote:
> Hi kazu
>
> After Iapply this patch, it is still broken.
>
> Here are some errors.
> crash_latest_fix_k66> mod -d sysdump
> crash_latest_fix_k66> set debug 1
> debug: 1
> crash_latest_fix_k66> mod -s sysdump
> ffffffxxx__ksymtab
> ffffffxxx __kcrctab
> ffffffxxx .altinstructions
> ffffffxxx __bug_table
> ffffffxxx __jump_table
> ffffffxxx .bss
> ffffffxxx .data
> ffffffxxx.rodata
> ..............
> .............
> ffffffxxx .note.gnu.build-id
> ffffffxxx .note.gnu.property
> ffffffxxx.symtab
> ffffffxxx .strtab
> /home/tianming.wang/workdir/kernel_6.6/sysdump.ko: add_symbol_file_kallsyms failed
Thanks for trying. Hmm, it can work well with a 6.6 dump on hand..
btw, does ".text" section exist in the section list above? It seems
that it's necessary for add_symbol_file_kallsyms() succeeds.
If the ".text" section exists, is it possible to determine where
"done"
is set to TRUE in the add_symbol_file_kallsyms()?
Thanks,
Kazu
(p.s. will be back on Tuesday..)
if (STREQ(section_name, ".text")) {
...
retval = TRUE;
Kazu
9:21 p.m.
New subject: crash8.0.4 cannot get source line nums of functions from ko on android15-k6.6
The log was not cut off last time. This is the entire log.
it seems ".text" exit in the list.
crash_latest_fix_k66> mod -d sysdump
crash_latest_fix_k66> set debug 1
debug: 1
crash_latest_fix_k66> mod -s sysdump
ffffffc07afb8000 __ksymtab
ffffffc07afb8060 __kcrctab
ffffffc07afb8080 .altinstructions
ffffffc07afa8000 __bug_table
ffffffc07afbc000 __jump_table
ffffffc07afa8010 .bss
ffffffc07afa84b8 .data
ffffffc07afb8248 .rodata
ffffffc07afa0000 .plt
ffffffc07afbe000 .init.plt
ffffffc07afa0a8c .text.ftrace_trampoline
ffffffc07afc9000 .init.eh_frame
ffffffc07afba370 .export_symbol
ffffffc07afa0a98 .text.sysdump_callback_register
ffffffc07afa0aa8 .text.sysdump_callback_unregiste
ffffffc07afa0ab8 .text.sprd_debug_check_crash_key
ffffffc07afa0c04 .text.sprd_vmalloc_or_module_add
ffffffc07afa0c40 .text.unisoc_virt_to_phys
ffffffc07afa0d0c .text.minidump_save_extend_infor
ffffffc07afa1080 .text.minidump_change_extend_inf
ffffffc07afa11bc .text.crash_note_save_cpu
ffffffc07afa1494 .text.sysdump_ipi
ffffffc07afa17cc .text.prepare_minidump_reg_memor
ffffffc07afa1aec .text.show_minidump_info
ffffffc07afa21d0 .text.minidump_init
ffffffc07afa25dc .text.show_exception_info
ffffffc07afa27dc .text.get_file_line_info
ffffffc07afa2830 .text.get_exception_stack_info
ffffffc07afa2af4 .text.prepare_dump_info_for_wdh
ffffffc07afa2b30 .text.prepare_minidump_info
ffffffc07afa2bd8 .text.prepare_exception_info
ffffffc07afa2da0 .text.sysdump_sysctl_exit
ffffffc07afa2f50 .text.init_module
ffffffc07afa3f30 .text.rcu_lock_acquire
ffffffc07afa3f70 .text.rcu_lock_release
ffffffc07afa3f9c .text.minidump_info_open
ffffffc07afa3fcc .text.minidump_info_read
ffffffc07afa4020 .text.ylog_buffer_map
ffffffc07afa40a8 .text.ylog_buffer_open
ffffffc07afa40b4 .text.dump_die_cb
ffffffc07afa4118 .text.sysdump_event
ffffffc07afa4150 .text.sysdump_connect
ffffffc07afa420c .text.sysdump_disconnect
ffffffc07afa4240 .text.sysdump_panic_event
ffffffc07afa4980 .text.per_cpu_funcs_register
ffffffc07afa49fc .text.sprd_sysdump_open
ffffffc07afa4a2c .text.sprd_sysdump_write
ffffffc07afa4ce8 .text.sprd_sysdump_read
ffffffc07afb01d0 __dyndbg
ffffffc07afc0000 .init.data
ffffffc07afb0ba8 .exit.data
ffffffc07afa4d24 .text.append_elf_note
ffffffc07afa4dbc .text.final_note
ffffffc07afa4dcc .text.update_vmcoreinfo_note
ffffffc07afa4e24 .text.crash_update_vmcoreinfo_sa
ffffffc07afa4e70 .text.crash_save_vmcoreinfo
ffffffc07afa4ef8 .text.vmcoreinfo_append_str
ffffffc07afa5008 .text.paddr_vmcoreinfo_note
ffffffc07afa5048 .text.crash_save_vmcoreinfo_init
ffffffc07afa5594 .text.crash_save_vmcoreinfo_exit
ffffffc07afa55e0 .text.sysdump_get_kmsg_to_buffer
ffffffc07afa5680 .text.last_kmsg_init
ffffffc07afa5b90 .text.last_kmsg_exit
ffffffc07afa5ca0 .text.kmsg_get_thread
ffffffc07afa5db0 .text.save_log_to_partition_hand
ffffffc07afa6040 .text.get_last_kmsg
ffffffc07afa6120 .text.last_kmsg_handler
ffffffc07afba3f0 __ksymtab_strings
ffffffc07afba4c4 .note.Linux
ffffffc07afb0bc0 .gnu.linkonce.this_module
ffffffc07afba4f4 .note.gnu.build-id
ffffffc07afba518 .note.gnu.property
ffffffc07afc0008 .symtab
ffffffc07afc4928 .strtab
/home/tianming.wang/workdir/kernel_6.6/sysdump.ko: add_symbol_file_kallsyms failed
add-symbol-file /home/tianming.wang/workdir/kernel_6.6/sysdump.ko 0xffffffc07afa0000 -s
.data 0xffffffc07afa84b8 -s .bss 0xffffffc07afa8010 -s .rodata 0xffffffc07afb8248
add symbol table from file "/home/tianming.wang/workdir/kernel_6.6/sysdump.ko"
at
.text_addr = 0xffffffc07afa0000
.data_addr = 0xffffffc07afa84b8
.bss_addr = 0xffffffc07afa8010
.rodata_addr = 0xffffffc07afb8248
MODULE NAME TEXT_BASE SIZE OBJECT FILE
ffffffc07afb0bc0 sysdump ffffffc07afa0000 106496
/home/tianming.wang/workdir/kernel_6.6/sysdump.ko
1:39 a.m.
New subject: crash8.0.4 cannot get source line nums of functions from ko on android15-k6.6
On 2024/03/01 12:21, tianming.wang(a)unisoc.com wrote:
The log was not cut off last time. This is the entire log.
it seems ".text" exit in the list.
Hmm, it looks no ".text" section to me.. a ".text" section exists
like
this in a vmcore on hand:
crash> mod -s xfs
ffffffffc07a3000 .note.gnu.build-id
ffffffffc07a3024 .note.Linux
ffffffffc0578000 .text << this one
ffffffffc067bb44 .static_call.text
ffffffffc054a000 .init.text
...
It looks like each function has its own section in your vmcore. I found
-ffunction-sections option of gcc, do you use this? probably the
current crash does not support this gcc option.
Just an experiment, how does the attached patch work?
Thanks,
Kazu
crash_latest_fix_k66> mod -d sysdump
crash_latest_fix_k66> set debug 1
debug: 1
crash_latest_fix_k66> mod -s sysdump
ffffffc07afb8000 __ksymtab
ffffffc07afb8060 __kcrctab
ffffffc07afb8080 .altinstructions
ffffffc07afa8000 __bug_table
ffffffc07afbc000 __jump_table
ffffffc07afa8010 .bss
ffffffc07afa84b8 .data
ffffffc07afb8248 .rodata
ffffffc07afa0000 .plt
ffffffc07afbe000 .init.plt
ffffffc07afa0a8c .text.ftrace_trampoline
ffffffc07afc9000 .init.eh_frame
ffffffc07afba370 .export_symbol
ffffffc07afa0a98 .text.sysdump_callback_register
ffffffc07afa0aa8 .text.sysdump_callback_unregiste
ffffffc07afa0ab8 .text.sprd_debug_check_crash_key
ffffffc07afa0c04 .text.sprd_vmalloc_or_module_add
ffffffc07afa0c40 .text.unisoc_virt_to_phys
ffffffc07afa0d0c .text.minidump_save_extend_infor
ffffffc07afa1080 .text.minidump_change_extend_inf
ffffffc07afa11bc .text.crash_note_save_cpu
ffffffc07afa1494 .text.sysdump_ipi
ffffffc07afa17cc .text.prepare_minidump_reg_memor
ffffffc07afa1aec .text.show_minidump_info
ffffffc07afa21d0 .text.minidump_init
ffffffc07afa25dc .text.show_exception_info
ffffffc07afa27dc .text.get_file_line_info
ffffffc07afa2830 .text.get_exception_stack_info
ffffffc07afa2af4 .text.prepare_dump_info_for_wdh
ffffffc07afa2b30 .text.prepare_minidump_info
ffffffc07afa2bd8 .text.prepare_exception_info
ffffffc07afa2da0 .text.sysdump_sysctl_exit
ffffffc07afa2f50 .text.init_module
ffffffc07afa3f30 .text.rcu_lock_acquire
ffffffc07afa3f70 .text.rcu_lock_release
ffffffc07afa3f9c .text.minidump_info_open
ffffffc07afa3fcc .text.minidump_info_read
ffffffc07afa4020 .text.ylog_buffer_map
ffffffc07afa40a8 .text.ylog_buffer_open
ffffffc07afa40b4 .text.dump_die_cb
ffffffc07afa4118 .text.sysdump_event
ffffffc07afa4150 .text.sysdump_connect
ffffffc07afa420c .text.sysdump_disconnect
ffffffc07afa4240 .text.sysdump_panic_event
ffffffc07afa4980 .text.per_cpu_funcs_register
ffffffc07afa49fc .text.sprd_sysdump_open
ffffffc07afa4a2c .text.sprd_sysdump_write
ffffffc07afa4ce8 .text.sprd_sysdump_read
ffffffc07afb01d0 __dyndbg
ffffffc07afc0000 .init.data
ffffffc07afb0ba8 .exit.data
ffffffc07afa4d24 .text.append_elf_note
ffffffc07afa4dbc .text.final_note
ffffffc07afa4dcc .text.update_vmcoreinfo_note
ffffffc07afa4e24 .text.crash_update_vmcoreinfo_sa
ffffffc07afa4e70 .text.crash_save_vmcoreinfo
ffffffc07afa4ef8 .text.vmcoreinfo_append_str
ffffffc07afa5008 .text.paddr_vmcoreinfo_note
ffffffc07afa5048 .text.crash_save_vmcoreinfo_init
ffffffc07afa5594 .text.crash_save_vmcoreinfo_exit
ffffffc07afa55e0 .text.sysdump_get_kmsg_to_buffer
ffffffc07afa5680 .text.last_kmsg_init
ffffffc07afa5b90 .text.last_kmsg_exit
ffffffc07afa5ca0 .text.kmsg_get_thread
ffffffc07afa5db0 .text.save_log_to_partition_hand
ffffffc07afa6040 .text.get_last_kmsg
ffffffc07afa6120 .text.last_kmsg_handler
ffffffc07afba3f0 __ksymtab_strings
ffffffc07afba4c4 .note.Linux
ffffffc07afb0bc0 .gnu.linkonce.this_module
ffffffc07afba4f4 .note.gnu.build-id
ffffffc07afba518 .note.gnu.property
ffffffc07afc0008 .symtab
ffffffc07afc4928 .strtab
/home/tianming.wang/workdir/kernel_6.6/sysdump.ko: add_symbol_file_kallsyms failed
add-symbol-file /home/tianming.wang/workdir/kernel_6.6/sysdump.ko 0xffffffc07afa0000 -s
.data 0xffffffc07afa84b8 -s .bss 0xffffffc07afa8010 -s .rodata 0xffffffc07afb8248
add symbol table from file "/home/tianming.wang/workdir/kernel_6.6/sysdump.ko"
at
.text_addr = 0xffffffc07afa0000
.data_addr = 0xffffffc07afa84b8
.bss_addr = 0xffffffc07afa8010
.rodata_addr = 0xffffffc07afb8248
MODULE NAME TEXT_BASE SIZE OBJECT FILE
ffffffc07afb0bc0 sysdump ffffffc07afa0000 106496
/home/tianming.wang/workdir/kernel_6.6/sysdump.ko
--
Crash-utility mailing list -- devel(a)lists.crash-utility.osci.io
To unsubscribe send an email to devel-leave(a)lists.crash-utility.osci.io
https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/
Contribution Guidelines: https://github.com/crash-utility/crash/wiki
116
days inactive
151
days old
devel@lists.crash-utility.osci.io
14 comments
3 participants
participants (3)
-
HAGIO KAZUHITO(萩尾 一仁) -
tianming.wang＠unisoc.com -
王天明 (Tianming Wang)