This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: GDB internal error in pc_in_thread_step_range

From: Simon Marchi <simon dot marchi at polymtl dot ca>
To: Eli Zaretskii <eliz at gnu dot org>
Cc: gdb-patches at sourceware dot org
Date: Wed, 19 Dec 2018 19:16:15 -0500
Subject: Re: GDB internal error in pc_in_thread_step_range
References: <83h8kjr8r6.fsf@gnu.org> <100001f1b27aa7d90902a75d5db37710@polymtl.ca> <83a7m6tk92.fsf@gnu.org> <e1065324-72b2-1a80-fccd-b5624ed9b37c@polymtl.ca> <8336qxfpjo.fsf@gnu.org> <bd38227d-30c4-36de-f12b-f41d11c28027@polymtl.ca> <83tvjde68l.fsf@gnu.org> <f52ef14d-448b-aecd-3714-e3d87c9bc57b@polymtl.ca> <83ftutcy7p.fsf@gnu.org>

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 canproduce with x86_64-w64-mingw32-gcc (and it looks similar, given theaddresses you show), your "image base" is likely 0x400000, and "base ofcode" 0x1000 (0x401000 in absolute). I found this information using"objdump -x", in the header somewhere. I therefore expect all textsymbols to be >= 0x401000. I would start digging why this text symbolwith a value of 0 exists.

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

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

Assuming this minimal symbol is wrong and assuming it wasn't there, thenI guess the search would fail and we would fall in the "Cannot findbounds of current function" case of prepare_one_step? That would beappropriate in this case.

In particular, I am looking for why we identified the symbolrepresented by MSYMBOLas the function containing PC. What is this symbol's name? Thatwould 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,