This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: GDB internal error in pc_in_thread_step_range
> Cc: gdb-patches@sourceware.org
> From: Simon Marchi <simon.marchi@polymtl.ca>
> Date: Sun, 16 Dec 2018 13:06:27 -0500
>
> >>> cache_pc_function_low = BMSYMBOL_VALUE_ADDRESS (msymbol);
> >>> cache_pc_function_name = MSYMBOL_LINKAGE_NAME (msymbol.minsym);
> >>> cache_pc_function_section = section;
> >>> cache_pc_function_high = minimal_symbol_upper_bound (msymbol);
> >>> cache_pc_function_block = nullptr;
> >>>
> >>> This is part of find_pc_partial_function. I verified that
> >>> minimal_symbol_upper_bound returns 1 in this case, and that this value
> >>> of 1 is assigned here:
> >>>
> >>> obj_section = MSYMBOL_OBJ_SECTION (minsym.objfile, minsym.minsym);
> >>> if (MSYMBOL_LINKAGE_NAME (msymbol + i) != NULL
> >>> && (MSYMBOL_VALUE_ADDRESS (minsym.objfile, msymbol + i)
> >>> < obj_section_endaddr (obj_section)))
> >>> result = MSYMBOL_VALUE_ADDRESS (minsym.objfile, msymbol + i); <<<<<<
> >>> else
> >>>
> >>> Once again, I'm not an expert on this stuff, but just thinking about
> >>> the situation, what else could GDB return in this case?
> >>
> >> This means that BMSYMBOL_VALUE_ADDRESS (msymbol) returned 0? What is that symbol?
The symbol is the one shown by GDB:
0x0040126d in __register_frame_info ()
Single stepping until exit from function __register_frame_info,
which has no line number information.
Here it is as shown in the debugging session:
227 msymbol = lookup_minimal_symbol_by_pc_section (mapped_pc, section);
(top-gdb)
228 ALL_OBJFILES (objfile)
(top-gdb) p msymbol
$3 = {minsym = 0x10450d38, objfile = 0x10443b48}
(top-gdb) p msymbol.minsym.mginfo.name
$4 = 0x104485cd "__register_frame_info"
(top-gdb) p msymbol.minsym.mginfo
$5 = {name = 0x104485cd "__register_frame_info", value = {ivalue = 0,
block = 0x0, bytes = 0x0, address = 0x0, common_block = 0x0,
chain = 0x0}, language_specific = {obstack = 0x0, demangled_name = 0x0},
language = language_auto, ada_mangled = 0, section = 0}
> In particular, I am looking for why we identified the symbol represented by MSYMBOL
> as the function containing PC. What is this symbol's name? That would be printed
> with MSYMBOL_LINKAGE_NAME(msymbol.minsym), I think. Or if you expand,
> "msymbol.minsym.mginfo.name".
>
> What is its address (should be msymbol.minsym.mginfo.value.address)?
>
> >
> >> How come by looking up a symbol for PC (what is PC's value, btw) we found this symbol?
That's because it's the symbol with the lowest address that satisfies
all the conditions in lookup_minimal_symbol_by_pc_section. It goes
like this:
The loop which does a binary search through the minsyms finds the the
symbol immediately preceding the address of PC is this:
(top-gdb) p newobj
$28 = 26
(top-gdb) p msymbol[newobj]
$29 = {mginfo = {name = 0x10448845 "_image_base__", value = {
ivalue = 4194304, block = 0x400000, bytes = 0x400000 "MZ\220",
address = 0x400000, common_block = 0x400000, chain = 0x400000},
language_specific = {obstack = 0x0, demangled_name = 0x0},
language = language_auto, ada_mangled = 0, section = 0}, size = 0,
filename = 0x0, type = mst_abs, created_by_gdb = 0, target_flag_1 = 0,
target_flag_2 = 0, has_size = 0, hash_next = 0x0, demangled_hash_next = 0x0}
(our PC is 0x40126d).
Then this loop:
/* Skip various undesirable symbols. */
while (hi >= 0)
{
decrements 'hi' all the way down to 5, because all the preceding
symbols have the type mst_abs:
(top-gdb) p hi
$46 = 5
(top-gdb) p msymbol[hi]
$47 = {mginfo = {name = 0x1044858d "__register_frame_info", value = {
ivalue = 0, block = 0x0, bytes = 0x0, address = 0x0,
common_block = 0x0, chain = 0x0}, language_specific = {obstack = 0x0,
demangled_name = 0x0}, language = language_auto, ada_mangled = 0,
section = 0}, size = 0, filename = 0x0, type = mst_text,
created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size = 0,
hash_next = 0x0, demangled_hash_next = 0x0}
Note that this symbol's address is zero. This symbol is then
returned, and so cache_pc_function_low becomes zero. Then we get to
this:
cache_pc_function_high = minimal_symbol_upper_bound (msymbol);
minimal_symbol_upper_bound then looks at the following symbols trying
to find the one whose address is different from zero:
for (i = 1; MSYMBOL_LINKAGE_NAME (msymbol + i) != NULL; i++)
{
if ((MSYMBOL_VALUE_RAW_ADDRESS (msymbol + i)
!= MSYMBOL_VALUE_RAW_ADDRESS (msymbol))
&& MSYMBOL_SECTION (msymbol + i) == section)
break;
}
It finds such a symbol in the 10th entry:
(top-gdb) p msymbol[1]
$76 = {mginfo = {name = 0x10448a55 "__set_app_type", value = {ivalue = 0,
block = 0x0, bytes = 0x0, address = 0x0, common_block = 0x0,
chain = 0x0}, language_specific = {obstack = 0x0,
demangled_name = 0x0}, language = language_auto, ada_mangled = 0,
section = 0}, size = 0, filename = 0x0, type = mst_abs,
created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size = 0,
hash_next = 0x0, demangled_hash_next = 0x0}
(top-gdb) p msymbol[2]
$77 = {mginfo = {name = 0x104487ad "_dll__", value = {ivalue = 0,
block = 0x0, bytes = 0x0, address = 0x0, common_block = 0x0,
chain = 0x0}, language_specific = {obstack = 0x0,
demangled_name = 0x0}, language = language_auto, ada_mangled = 0,
section = 0}, size = 0, filename = 0x0, type = mst_abs,
created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size = 0,
hash_next = 0x0, demangled_hash_next = 0x0}
(top-gdb) p msymbol[3]
$78 = {mginfo = {name = 0x104483cd "_dll_characteristics__", value = {
ivalue = 0, block = 0x0, bytes = 0x0, address = 0x0,
common_block = 0x0, chain = 0x0}, language_specific = {obstack = 0x0,
demangled_name = 0x0}, language = language_auto, ada_mangled = 0,
section = 0}, size = 0, filename = 0x0, type = mst_abs,
created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size = 0,
hash_next = 0x0, demangled_hash_next = 0x0}
(top-gdb) p msymbol[3]
$79 = {mginfo = {name = 0x104483cd "_dll_characteristics__", value = {
ivalue = 0, block = 0x0, bytes = 0x0, address = 0x0,
common_block = 0x0, chain = 0x0}, language_specific = {obstack = 0x0,
demangled_name = 0x0}, language = language_auto, ada_mangled = 0,
section = 0}, size = 0, filename = 0x0, type = mst_abs,
created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size = 0,
hash_next = 0x0, demangled_hash_next = 0x0}
(top-gdb) p msymbol[4]
$80 = {mginfo = {name = 0x1044868d "_fpreset", value = {ivalue = 0,
block = 0x0, bytes = 0x0, address = 0x0, common_block = 0x0,
chain = 0x0}, language_specific = {obstack = 0x0,
demangled_name = 0x0}, language = language_auto, ada_mangled = 0,
section = 0}, size = 0, filename = 0x0, type = mst_abs,
created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size = 0,
hash_next = 0x0, demangled_hash_next = 0x0}
(top-gdb) p msymbol[5]
$81 = {mginfo = {name = 0x1044fead "_loader_flags__", value = {ivalue = 0,
block = 0x0, bytes = 0x0, address = 0x0, common_block = 0x0,
chain = 0x0}, language_specific = {obstack = 0x0,
demangled_name = 0x0}, language = language_auto, ada_mangled = 0,
section = 0}, size = 0, filename = 0x0, type = mst_abs,
created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size = 0,
hash_next = 0x0, demangled_hash_next = 0x0}
(top-gdb) p msymbol[6]
$82 = {mginfo = {name = 0x1044ff9d "_minor_image_version__", value = {
ivalue = 0, block = 0x0, bytes = 0x0, address = 0x0,
common_block = 0x0, chain = 0x0}, language_specific = {obstack = 0x0,
demangled_name = 0x0}, language = language_auto, ada_mangled = 0,
section = 0}, size = 0, filename = 0x0, type = mst_abs,
created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size = 0,
hash_next = 0x0, demangled_hash_next = 0x0}
(top-gdb) p msymbol[7]
$83 = {mginfo = {name = 0x104487cd "_minor_os_version__", value = {
ivalue = 0, block = 0x0, bytes = 0x0, address = 0x0,
common_block = 0x0, chain = 0x0}, language_specific = {obstack = 0x0,
demangled_name = 0x0}, language = language_auto, ada_mangled = 0,
section = 0}, size = 0, filename = 0x0, type = mst_abs,
created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size = 0,
hash_next = 0x0, demangled_hash_next = 0x0}
(top-gdb) p msymbol[8]
$84 = {mginfo = {name = 0x1044ff65 "_minor_subsystem_version__", value = {
ivalue = 0, block = 0x0, bytes = 0x0, address = 0x0,
common_block = 0x0, chain = 0x0}, language_specific = {obstack = 0x0,
demangled_name = 0x0}, language = language_auto, ada_mangled = 0,
section = 0}, size = 0, filename = 0x0, type = mst_abs,
created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size = 0,
hash_next = 0x0, demangled_hash_next = 0x0}
(top-gdb) p msymbol[9]
$85 = {mginfo = {name = 0x10448b35 "_rt_psrelocs_size", value = {ivalue = 0,
block = 0x0, bytes = 0x0, address = 0x0, common_block = 0x0,
chain = 0x0}, language_specific = {obstack = 0x0,
demangled_name = 0x0}, language = language_auto, ada_mangled = 0,
section = 0}, size = 0, filename = 0x0, type = mst_abs,
created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size = 0,
hash_next = 0x0, demangled_hash_next = 0x0}
(top-gdb) p msymbol[10]
$86 = {mginfo = {name = 0x1044fe8d "_major_image_version__", value = {
ivalue = 1, block = 0x1,
bytes = 0x1 <error: Cannot access memory at address 0x1>,
address = 0x1, common_block = 0x1, chain = 0x1}, language_specific = {
obstack = 0x0, demangled_name = 0x0}, language = language_auto,
ada_mangled = 0, section = 0}, size = 0, filename = 0x0, type = mst_abs,
created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size = 0,
hash_next = 0x0, demangled_hash_next = 0x0}
And so cache_pc_function_high becomes 1.
> Actually, I think I would investigate this line in find_pc_partial_function:
>
> msymbol = lookup_minimal_symbol_by_pc_section (mapped_pc, section);
>
> This is where we ask the question "which is the closest minimal symbol that is <= than PC".
> I would then try to see if the returned msymbol makes sense. If you can give its name and
> address, it would be a good start. If we find it doesn't make sense, I'd start looking at
> why lookup_minimal_symbol_by_pc_section returned that.
That's what I did. The problem seems to be that the low value of PC
doesn't allow GDB to find a reasonable symbol; what it finds are
symbols with very low addresses, which don't look like symbols
relevant to the issue at hand. I see the same symbols and addresses
in the output of "objdump -t" (I can show it if you want).
Where do we go from here?
Thanks.