Re: GDB internal error in pc_in_thread_step_range

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 22 Dec 2018 11:47:07 -0500
> From: Simon Marchi <simon.marchi@polymtl.ca>
> Cc: gdb-patches@sourceware.org
> 
> >> Huh, interesting.  I looked at elfread, and similar undefined symbols
> >> are skipped:
> >> 
> >> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/elfread.c;h=71e6fcca6ec62ec57f93f06d8a9913612be6f9e2;hb=HEAD#l270
> > 
> > So maybe GDB should skip them as well?
> 
> Yes.  Can you please give it a try it?

Like this?

--- gdb/coffread.c~1	2018-07-04 18:41:59.000000000 +0300
+++ gdb/coffread.c	2018-12-23 10:24:15.758116900 +0200
@@ -874,8 +874,10 @@ coff_symtab_read (minimal_symbol_reader 
 	  int section = cs_to_section (cs, objfile);
 
 	  tmpaddr = cs->c_value;
-	  record_minimal_symbol (reader, cs, tmpaddr, mst_text,
-				 section, objfile);
+	  /* Don't record unresolved symbols.  */
+	  if (!(cs->c_secnum <= 0 && cs->c_value == 0))
+	    record_minimal_symbol (reader, cs, tmpaddr, mst_text,
+				   section, objfile);
 
 	  fcn_line_ptr = main_aux.x_sym.x_fcnary.x_fcn.x_lnnoptr;
 	  fcn_start_addr = tmpaddr;

> >> Note that if we implement the solution of rejecting the symbols with
> >> section == -1, those mst_abs symbols won't be there anymore.
> > 
> > Fine by me.  Should we push such a change?
> 
> Based on what we saw, I would be for it.  But you'll need to make the 
> change and test it for regression, as I don't have the necessary setup 
> (and knowledge) to do that on Windows.

I'm sorry, I don't have such a setup, either.  Can anyone else run the
regression tests?  If not, how are MinGW related changes tested when
submitted here?

> >> So it kind of works for your use case, but it's not right, IMO.  If 
> >> the
> >> process did not exit as it does here, the behavior would be erratic.
> > 
> > I don't think it would be erratic, we will just see the same
> > 
> >     0x00401nnn in __register_frame_info ()
> > 
> > for several steps.  Is that so bad?
> 
> Well, first thing, I think it's wrong that we show that it's in 
> __register_frame_info.  If this was an actual resolved .text symbol, it 
> wouldn't be so bad, but here it's not even a function in the program, it 
> doesn't make sense.

The change above causes the following behavior, when stepping out of
'main' with "next":

  6         return 0;
  (gdb) n
  7       }
  (gdb)
  0x00401288 in ?? ()
  (gdb) n
  Cannot find bounds of current function
  (gdb) c
  Continuing.
  [Inferior 1 (process 9228) exited normally]
  (gdb) q

If this is fine with you, it's fine with me.

Thanks.