GDB 7.4 adds shlib_events BPs, casuing problem in debugging vmlinux

GDB 7.4 adds shlib_events BPs, casuing problem in debugging vmlinux

[Joakim Tjernlund]

Using above gdb I get this when trying to debug a kernel with a BDI2000 emulator:
#> powerpc-softfloat_4.5.3-linux-gnu-gdb vmlinux
GNU gdb (Gentoo 7.4 p1) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=powerpc-softfloat_4.5.3-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /usr/local/src/kenth_os2kernel.git/vmlinux...done.
(gdb) tar remote bdi:2001
Remote debugging using bdi:2001
0xeff80050 in ?? ()
(gdb) mon reset
(gdb) cont
Continuing.
Warning:
Cannot insert breakpoint -1.
Error accessing memory address 0xc0000000: Unknown error 4294967295.

This ia because gdb always inserts a special BP:

(gdb) maintenance info breakpoints
Num     Type           Disp Enb Address    What
-1      shlib events   keep y   0xc0000000 <_stext> inf 1

I cannot get rid of this shared lib BP.
Also linux does not use shard libs so why is it inserted in the fist place?
Is there some tweak I can use to disable this BP(patch even)?

 Jocke

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

[Jan Kratochvil]

On Thu, 31 May 2012 02:31:17 +0200, Joakim Tjernlund wrote:
> 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"
> > 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.
> > "_start" is the possible symbol there how to catch just exit from ld.so.
> 
> BTW, if this is all about ld.so, then why not guard this with
> if (interp_name) /* Check if there is a ld.so at all */
> {
> ...
> }

Yes, I think this should work - to omit "_start" and "__start" if there is no
INTERP_NAME.


Thanks,
Jan

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

[Joakim Tjernlund]

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

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

[Joakim Tjernlund]

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"
> 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.
> "_start" is the possible symbol there how to catch just exit from ld.so.

BTW, if this is all about ld.so, then why not guard this with
if (interp_name) /* Check if there is a ld.so at all */
{
...
}

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

[Joakim Tjernlund]

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

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

[Jan Kratochvil]

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"
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.
"_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
could try hardware breakpoint if software breakpoint fails due to read-only
memory.


Regards,
Jan

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

[Joakim Tjernlund]

Joakim Tjernlund/Transmode wrote on 2012/05/30 15:47:56:
>
> Using above gdb I get this when trying to debug a kernel with a BDI2000 emulator:
> #> powerpc-softfloat_4.5.3-linux-gnu-gdb vmlinux
> GNU gdb (Gentoo 7.4 p1) 7.4
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu --target=powerpc-softfloat_4.5.3-linux-gnu".
> For bug reporting instructions, please see:
> <http://bugs.gentoo.org/>...
> Reading symbols from /usr/local/src/kenth_os2kernel.git/vmlinux...done.
> (gdb) tar remote bdi:2001
> Remote debugging using bdi:2001
> 0xeff80050 in ?? ()
> (gdb) mon reset
> (gdb) cont
> Continuing.
> Warning:
> Cannot insert breakpoint -1.
> Error accessing memory address 0xc0000000: Unknown error 4294967295.
>
> This ia because gdb always inserts a special BP:
>
> (gdb) maintenance info breakpoints
> Num     Type           Disp Enb Address    What
> -1      shlib events   keep y   0xc0000000 <_stext> inf 1
>
> I cannot get rid of this shared lib BP.
> Also linux does not use shard libs so why is it inserted in the fist place?
> Is there some tweak I can use to disable this BP(patch even)?

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

 Jocke