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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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