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

[Joakim Tjernlund <joakim dot tjernlund at transmode dot se>]

Joakim Tjernlund/Transmode wrote on 2012/05/31 00:36:18:
>
> 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)

With this small patch it works both cases:
--- remote.c.org	2012-05-31 12:45:04.655541485 +0200
+++ remote.c	2012-05-31 15:21:24.273296844 +0200
@@ -3293,7 +3293,7 @@
       /* Now, if we have thread information, update inferior_ptid.  */
       inferior_ptid = remote_current_thread (inferior_ptid);

-      remote_add_inferior (ptid_get_pid (inferior_ptid), -1);
+      remote_add_inferior (ptid_get_pid (inferior_ptid), 1);

       /* Always add the main thread.  */
       add_thread_silent (inferior_ptid);

What do you think?

 Jocke