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
On 2018-12-23 11:10 a.m., Eli Zaretskii wrote:
> 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;
That looks good to me.
> 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?
I thought you were the MinGW reference around here :). I guess the changes should
be validated the same way we do on GNU/Linux, run the testsuite without and with the
patch applied, diff the gdb.sum files to see if there's any regression. I don't
know what's the state of the testsuite on Windows though...
Running the testsuite is done using "make check". There are some tips on this page:
https://sourceware.org/gdb/wiki/TestingGDB
> 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.
That seems good to me, given the information GDB works with.
Simon