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: Thu, 20 Dec 2018 18:03:33 -0500
> From: Simon Marchi <simon.marchi@polymtl.ca>
> Cc: gdb-patches@sourceware.org
>
> >> Ok. Well this is already strange. Why is there an mst_text (code)
> >> symbol with a value of 0?
> >
> > Its address is zero because it's an unresolved symbol:
> >
> > d:\usr\eli>nm -A hello0.exe | fgrep " U "
> > hello0.exe: U ___deregister_frame_info
> > hello0.exe: U ___register_frame_info
> > hello0.exe: U __Jv_RegisterClasses
>
> 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?
> > This symbol comes from a weak symbol defined in MinGW crtbegin.o:
> >
> > d:\usr\eli>nm -A lib/gcc/mingw32/6.3.0/crtbegin.o | fgrep _frame_info
> > lib/gcc/mingw32/6.3.0/crtbegin.o:00000000 A
> > .weak.___deregister_frame_info.___EH_FRAME_BEGIN__
> > lib/gcc/mingw32/6.3.0/crtbegin.o:00000000 A
> > .weak.___register_frame_info.___EH_FRAME_BEGIN__
> > lib/gcc/mingw32/6.3.0/crtbegin.o: w ___deregister_frame_info
> > lib/gcc/mingw32/6.3.0/crtbegin.o: w ___register_frame_info
>
> Is crtbegin.o an object file you link with statically when compiling
> with mingw?
Yes. This file comes with MinGW GCC.
> If so, why would you end up with an undefined reference in
> the final executable? Or is it linked dynamically at runtime?
AFAIU, these symbols are only resolved when linking a Java program
using gcj. See the comments in GCC's source file
libgcc/config/i386/cygming-crtbegin.c, which is where crtbegin.o comes
from.
> > In any case, if we do call the "Cannot find bounds of current
> > function" error, that will throw to the command loop, which I think is
> > undesirable in this case. We want GDB to step out of this code, not
> > to error out.
>
> When we have no line information for the current PC and the user asks us
> to step, we fall back to "single step until out of the current
> function". But if the minimal symbol information doesn't let us know
> the bounds of the current function, then we can't "single step until out
> of the current function", because we don't know where it starts/end.
>
> In your binary, the lowest .text function symbol is
> __mingw32_init_mainargs at 0x000002a0 (0x4012a0 once relocated). Your
> pc is 0x40126d (according to an earlier message, but reading lower I
> realize this may not be valid anymore), which is lower. So there's just
> no minimal symbol for GDB to find. In that case, it sounds right to
> error our and say "I can't step, I don't have enough information". The
> user can still use stepi.
But this use case is somewhat special, IMO: stepping outside of 'main'
can happen unintentionally, and should not cause an error. It should
let the inferior run to completion without any errors. Raising an
error in this case is confusing.
> Side-question, are there some debug symbols in the binary that could
> describe this location?
How do I know that?
> Which debug format (DWARF or equivalent) is generated when you use
> -g with mingw?
It's DWARF2 version 4.
> > --- gdb/minsyms.c~0 2018-07-04 18:41:59.000000000 +0300
> > +++ gdb/minsyms.c 2018-12-20 08:06:11.516834500 +0200
> > @@ -1514,7 +1514,8 @@ minimal_symbol_upper_bound (struct bound
> > {
> > if ((MSYMBOL_VALUE_RAW_ADDRESS (msymbol + i)
> > != MSYMBOL_VALUE_RAW_ADDRESS (msymbol))
> > - && MSYMBOL_SECTION (msymbol + i) == section)
> > + && MSYMBOL_SECTION (msymbol + i) == section
> > + && MSYMBOL_TYPE (msymbol + i) != mst_abs)
> > break;
> > }
>
> 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?
> > I think if we want to avoid showing __register_frame_info, we need
> > further changes in lookup_minimal_symbol_by_pc_section. But I don't
> > see how this will help us, unless we also allow displaying the above
> > message for functions whose names we don't know, perhaps saying
> > something like
> >
> > Single stepping until exit from function <unknown>
>
> The problem is not only that we are missing the name, but most
> importantly that we are missing the bounds of the current function.
> With what you've implemented here, GDB thinks there is a function that
> occupies the range [0,401000[ (something like that), so it single steps
> until it gets out of that range, but the process exits before.
Which IMO is just fine for this specific use case.
> 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?
> Ok, well I think it shows the problem quite clearly, some symbol is
> missing for GDB to work properly in that context. I think that we
> should improve GDB to handle it better error out clearly (instead of
> hitting a failed assert), but I don't think it can do much more.
Can you suggest a patch? I'm not sure I understand the behavior that
will be the result.
> I guess that having debug info for the file containing
> __mingw_CRTStartup would help, if you really needed to step past main?
I don't need to step past main, it just happens in many cases, when I
type one "next" too many. I would like to avoid any errors in that
case.