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 12:06:07 -0500
> 
> I can't see any mention or even clue that these values would have a special
> meaning, it looks to me like they are returned by mistake more than on purpose.

If the start address is zero and the length is zero, this is what we
will get, right?

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

Please help me understand what field of which struct do I need to show
to answer that question.  IOW, when you ask "what is that symbol",
what kind of answer do you expect me to provide?

> How come by looking up a symbol for PC (what is PC's value, btw) we found this symbol?

It comes from this loop, just before the above-mentioned snippet from
minimal_symbol_upper_bound:

  msymbol = minsym.minsym;
  section = MSYMBOL_SECTION (msymbol);
  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;
    }

> > --- gdb/infrun.c~0	2018-07-04 18:41:59.000000000 +0300
> > +++ gdb/infrun.c	2018-12-16 11:02:24.103425700 +0200
> > @@ -2713,7 +2713,13 @@ resume_1 (enum gdb_signal sig)
> >        displaced_step_dump_bytes (gdb_stdlog, buf, sizeof (buf));
> >      }
> >  
> > -  if (tp->control.may_range_step)
> > +  if (tp->control.may_range_step
> > +      /* If .step_range_start == 0 and .step_range_end == 1, we don't
> > +	 really know the step range, so don't check in that case.
> > +	 (This is known to happen on MinGW when stepping the program
> > +	 epilogue code after 'main' returns.)  */
> > +      && !(tp->control.step_range_start == 0x0
> > +	   && tp->control.step_range_end == 0x1))
> >      {
> >        /* If we're resuming a thread with the PC out of the step
> >  	 range, then we're doing some nested/finer run control
> 
> This is treating 0 and 1 as special values, which I don't think they are.

It definitely looked to me as if they were special.  But I will try to
answer your other questions, maybe I was wrong.

Thanks.