Re: GDB internal error in pc_in_thread_step_range

[Eli Zaretskii <eliz@gnu.org>]

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