Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
gdb: fix "p" command to print module variables correctly
Some objects format may potentially support copy relocations, but currently the maybe_copied is always initialized to 0 in the symbol(). And the type is 'mst_file_bss', not always the 'mst_bss' or 'mst_data' in the lookup_minimal_symbol_linkage(). For example: (gdb) p *msymbol $42 = {<general_symbol_info> = {m_name = 0x349812f "test_no_static", value = {ivalue = 8, block = 0x8, bytes = 0x8 <error: Cannot access memory at address 0x8>, address = 8, common_block = 0x8, chain = 0x8}, language_specific = { obstack = 0x0, demangled_name = 0x0}, m_language = language_auto, ada_mangled = 0, section = 20}, size = 4, filename = 0x6db3440 "test_sanity.c", type = mst_file_bss, created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size = 1, maybe_copied = 0, name_set = 1, hash_next = 0x0, demangled_hash_next = 0x0} This causes a problem that the 'p' command cannot work well as expected, and emits an error or a bogus value: crash> mod -s test_sanity /home/test_sanity.ko MODULE NAME BASE SIZE OBJECT FILE ffffffffc1084040 test_sanity ffffffffc1082000 16384 /home/test_sanity.ko crash> p test_no_static p: gdb request failed: p test_no_static crash> The issue occurs with Linux 6.2 and later or kernels that have kernel commit 80e4c1cd42ff ("x86/retbleed: Add X86_FEATURE_CALL_DEPTH") and configured with CONFIG_CALL_DEPTH_TRACKING=y, including RHEL9.3 and later kernels. With the patch: crash> mod -s test_sanity /home/test_sanity.ko MODULE NAME BASE SIZE OBJECT FILE ffffffffc1084040 test_sanity ffffffffc1082000 16384 /home/test_sanity.ko crash> p test_no_static test_no_static = $1 = 5 crash> Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
- Loading branch information