Re: GDB internal error in pc_in_thread_step_range

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2018-12-19 10:50, Eli Zaretskii wrote:
> 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}

Ok.  Well this is already strange.  Why is there an mst_text (code) 
symbol with a value of 0?  If your binary is anything like those I can 
produce with x86_64-w64-mingw32-gcc (and it looks similar, given the 
addresses you show), your "image base" is likely 0x400000, and "base of 
code" 0x1000 (0x401000 in absolute).  I found this information using 
"objdump -x", in the header somewhere.  I therefore expect all text 
symbols to be >= 0x401000.  I would start digging why this text symbol 
with a value of 0 exists.

It would be interesting to look at some other symbols in the msymbols 
vector.  Are the other mst_text symbols >= 0x401000?

When printing the symbols with "objdump -t", the addresses are also 
relative to 0x401000, but when they become minimal symbols in GDB, they 
are saved as the absolute address (e.g. a text symbol at 0x1c88 becomes 
0x401000).

Assuming this minimal symbol is wrong and assuming it wasn't there, then 
I guess the search would fail and we would fall in the "Cannot find 
bounds of current function" case of prepare_one_step?  That would be 
appropriate in this case.

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

Ok, from what I understand, all these "mst_abs" symbols do not represent 
addresses.  They just represent numerical "values", like version 
numbers, alignment sizes, etc.  So it seems right to skip them when 
looking for the minimal symbol preceding pc.

It looks like minimal_symbol_upper_bound is buggy, in that it should not 
consider these mst_abs.  If we are looking for the end of a memory 
range, we should not consider those symbols that do not even represent 
memory addresses...

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

If you could pastebin it, or send it as an attachment, I think it would 
be useful.  Consider sending the output of "objdump -x", which I think 
gives a superset of "objdump -t".

> Where do we go from here?

I would say

1. investigate if the text symbol at address 0 really has business being 
there.
2. investigate if there should be some text symbol that should really 
contain 0x0040126d, that for some reason does not end up in GDB's 
minimal symbol table.

Simon