This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB 7.4 adds shlib_events BPs, casuing problem in debugging vmlinux
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Joakim Tjernlund <joakim dot tjernlund at transmode dot se>
- Cc: gdb at sourceware dot org
- Date: Wed, 30 May 2012 23:35:39 +0200
- Subject: Re: GDB 7.4 adds shlib_events BPs, casuing problem in debugging vmlinux
- References: <OF9A4BFC71.726F89BA-ONC1257A0E.004B4830-C1257A0E.004BCCB4@LocalDomain> <OF69216827.F4133E69-ONC1257A0E.004E9BAC-C1257A0E.004F3D27@transmode.se>
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,
> ¤t_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