This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: GDB internal error in pc_in_thread_step_range
> 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.