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

Joakim Tjernlund
2012-05-31T13:26:04Z

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