Re: GDB 7.4 adds shlib_events BPs, casuing problem in debugging vmlinux

[Joakim Tjernlund <joakim.tjernlund@transmode.se>]

Jan Kratochvil <jan.kratochvil@redhat.com> wrote on 2012/05/30 23:35:39:
>
> On Wed, 30 May 2012 16:25:29 +0200, Joakim Tjernlund wrote:
> > Found this in solib-svr4.c which I think is the problem:
> > static const char * const bkpt_names[] =
> > {
> >   "_start",
> >   "__start",
> >   "main",
> >   NULL
> > };
> > ...
> > ...
> >  if (!current_inferior ()->attach_flag)
> >     {
> >       for (bkpt_namep = bkpt_names; *bkpt_namep != NULL; bkpt_namep++)
> >    {
> >      msymbol = lookup_minimal_symbol (*bkpt_namep, NULL, symfile_objfile);
> >      if ((msymbol != NULL) && (SYMBOL_VALUE_ADDRESS (msymbol) != 0))
> >        {
> >          sym_addr = SYMBOL_VALUE_ADDRESS (msymbol);
> >          sym_addr = gdbarch_convert_from_func_ptr_addr (target_gdbarch,
> >                           sym_addr,
> >                           &current_target);
> >          create_solib_event_breakpoint (target_gdbarch, sym_addr);
> >          return 1;
> >        }
> >    }
> >     }
> >
> > This will insert the above BP just because the symbol  _start is present. Seems like
> > there are missing safe guards to avoid the unwanted BP
>
> This breakpoint is wanted.  If GDB fails to insert the "_r_debug_state"

No it is not. There are no shared libs in vmlinux, not even an interpreter
Seems to me that gdb tries too hard, it should stop if there is no "_r_debug_state"
or at least exclude _start from the list, should be enough with main.

> breakpoint into ld.so for whatever reason then after initial DT_NEEDED loading
> of shared libraries ld.so gives away control to the main executable.

There are no DT_NEEDED either, the dynamic section is not there.

> "_start" is the possible symbol there how to catch just exit from ld.so.
>
> It is more questionable why you cannot insert such breakpoint.  Maybe also GDB

Not when when using an emulator which will start from CPU reset and therefore there is no RAM
mapped at all.

> could try hardware breakpoint if software breakpoint fails due to read-only
> memory.

Yes I can do that but that doesn't solve the problem completely, the hidden BP
will consume one HW BP resource which I never get back. I only got 2 HW BPs
so I don't want to waste them.

Looking at: if (!current_inferior ()->attach_flag)
it is clear to me that this is not supposed to be executed if I am attached.
A quick test revels:
# > gdb
(gdb) tar rem bdi:2001
(gdb) file vmlinux
(gdb) maintenance info breakpoints
(gdb)

Now there is no BP so the attached test does not work when you
start gdb with vmlinux as argument(the most common use)

 Jocke