[RFC] solib-svr4.c: Never attempt to place breakpoints on _start, __start, or main

[RFC] solib-svr4.c: Never attempt to place breakpoints on _start, __start, or main

[Kevin Buettner]

I recently had a discussion with a colleague who, while debugging the
linux kernel using GDB, noticed that GDB is writing a breakpoint to
the _start address on every "step" and "continue".  He had not placed
a breakpoint at that address, nor did he want that address being
written to in the event that the page containing that address had
been recycled and was now being used for other purposes.

I have found some cruft in solib-svr4.c which is responsible for this
behavior -- well, I think it's cruft anyway.  There's a bit of code at
the end of enable_break() which, in desperation, attempts to place a
breakpoint on one of _start, __start, or main, in that order only when
all earlier attempts to place a shared library event breakpoint have
failed.  I have no doubt that there was probably some platform for
which this once worked and was perhaps even needed, probably back in
the days when GDB's SunOS and SVR4 shared library support was jumbled
together in one file.  I suspect that it may have been needed for
SunOS support but was copied over to the SVR4 file in an abundance of
caution.  I doubt that there's any recent SVR4-like platform which
requires this code.

I've tested the patch below on Fedora 13 x86_64 (native) and do not
see any regressions.

Comments?  (I.e. does anyone know of a platform or a situation where
the code that I'm deleting is still needed?)

	* solib-svr4.c (bkpt_names): Delete.
	(enable_break): Don't attempt to break on the names formerly in
	bkpt_names: "_start", "__start", and "main".

Index: solib-svr4.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-svr4.c,v
retrieving revision 1.138
diff -u -p -r1.138 solib-svr4.c
--- solib-svr4.c	3 Aug 2010 22:35:41 -0000	1.138
+++ solib-svr4.c	16 Sep 2010 22:15:30 -0000
@@ -74,11 +74,7 @@ struct lm_info
 
 /* On SVR4 systems, a list of symbols in the dynamic linker where
    GDB can try to place a breakpoint to monitor shared library
-   events.
-
-   If none of these symbols are found, or other errors occur, then
-   SVR4 systems will fall back to using a symbol as the "startup
-   mapping complete" breakpoint address.  */
+   events.  */
 
 static const char * const solib_break_names[] =
 {
@@ -92,14 +88,6 @@ static const char * const solib_break_na
   NULL
 };
 
-static const char * const bkpt_names[] =
-{
-  "_start",
-  "__start",
-  "main",
-  NULL
-};
-
 static const  char * const main_name_list[] =
 {
   "main_$main",
@@ -1607,19 +1595,6 @@ enable_break (struct svr4_info *info, in
 	}
     }
 
-  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;
-	}
-    }
   return 0;
 }
 

Re: [RFC] solib-svr4.c: Never attempt to place breakpoints on _start, __start, or main

[Daniel Jacobowitz]

On Thu, Sep 16, 2010 at 03:23:34PM -0700, Kevin Buettner wrote:
> Comments?  (I.e. does anyone know of a platform or a situation where
> the code that I'm deleting is still needed?)

I'm in favor of deleting this.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] solib-svr4.c: Never attempt to place breakpoints on _start, __start, or main

[Mark Kettenis]

> Date: Thu, 16 Sep 2010 15:23:34 -0700
> From: Kevin Buettner <kevinb@redhat.com>
> 
> I recently had a discussion with a colleague who, while debugging the
> linux kernel using GDB, noticed that GDB is writing a breakpoint to
> the _start address on every "step" and "continue".  He had not placed
> a breakpoint at that address, nor did he want that address being
> written to in the event that the page containing that address had
> been recycled and was now being used for other purposes.
> 
> I have found some cruft in solib-svr4.c which is responsible for this
> behavior -- well, I think it's cruft anyway.  There's a bit of code at
> the end of enable_break() which, in desperation, attempts to place a
> breakpoint on one of _start, __start, or main, in that order only when
> all earlier attempts to place a shared library event breakpoint have
> failed.  I have no doubt that there was probably some platform for
> which this once worked and was perhaps even needed, probably back in
> the days when GDB's SunOS and SVR4 shared library support was jumbled
> together in one file.  I suspect that it may have been needed for
> SunOS support but was copied over to the SVR4 file in an abundance of
> caution.  I doubt that there's any recent SVR4-like platform which
> requires this code.
> 
> I've tested the patch below on Fedora 13 x86_64 (native) and do not
> see any regressions.
> 
> Comments?  (I.e. does anyone know of a platform or a situation where
> the code that I'm deleting is still needed?)

Sorry, but I think that code is still useful.  Over the years I've
seen various cases where setting the breakpoint in the proper place
failed: the magic ld.so breakpoint function was renamed, somebody
stripped ld.so, GDB misinterpreted the debug information in ld.so.
The code you're removing makes sure (or at least attempts too make
sure) that you have a valid list of shared libraries as soon as you
hit main().

Obviously it is pointless to keep removing and reinserting these
breakpoints.  Perhaps they should be disabled as soon as one of them
has been hit?

Also, I think it is pointless to insert these if the program you're
debugging isn't using the dynamic linker.  I'm a little bit suprised
that the solib-svr4.c code is used at all when debugging the Linux
kernel.  Does the same thing happen for static binaries?

Re: [RFC] solib-svr4.c: Never attempt to place breakpoints on _start, __start, or main

[Kevin Buettner]

On Fri, 17 Sep 2010 10:10:18 +0200 (CEST)
Mark Kettenis <mark.kettenis@xs4all.nl> wrote:

> > Comments?  (I.e. does anyone know of a platform or a situation where
> > the code that I'm deleting is still needed?)
> 
> Sorry, but I think that code is still useful.  Over the years I've
> seen various cases where setting the breakpoint in the proper place
> failed: the magic ld.so breakpoint function was renamed, somebody
> stripped ld.so, GDB misinterpreted the debug information in ld.so.
> The code you're removing makes sure (or at least attempts too make
> sure) that you have a valid list of shared libraries as soon as you
> hit main().

Okay.

> Obviously it is pointless to keep removing and reinserting these
> breakpoints.  Perhaps they should be disabled as soon as one of them
> has been hit?

That sounds like a good idea.  It's not sufficient though for
debugging scenarios in which one attaches to a program that's
already gone past start or main.  Perhaps we should skip the
attempt to place a breakpoint on _start, __start, and main
when attaching?

> Also, I think it is pointless to insert these if the program you're
> debugging isn't using the dynamic linker.  I'm a little bit suprised
> that the solib-svr4.c code is used at all when debugging the Linux
> kernel.  Does the same thing happen for static binaries?

Yes, the same thing happens for static binaries.  Here's
"maint info breakpoints" when run on a static hello world program:

(gdb) maint info breakpoints
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x00000000004003f8 in main at hello.c:6 inf 1
        breakpoint already hit 1 time
-2      shlib events   keep y   0x000000000043a200 <_dl_debug_state> inf 1
-4      exception master keep n   0x0000000000469960 <_Unwind_DebugHook> inf 1

We don't have a breakpoint on _start, __start, or main, but that's
because _dl_debug_state was found first.  (The code searches for that
symbol and others like it first...)

If I edit the binary and change _dl_debug_state to _dl_rebug_state, I
can get a breakpoint set on _start:

(gdb) maint info break
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x00000000004003f8 in main at hello.c:6 inf 1
        breakpoint already hit 1 time
-2      shlib events   keep y   0x00000000004002e0 <_start> inf 1
        breakpoint already hit 1 time
-4      exception master keep n   0x0000000000469960 <_Unwind_DebugHook> inf 1

Kevin

Re: [RFC] solib-svr4.c: Never attempt to place breakpoints on _start, __start, or main

[Mark Kettenis]

> Date: Fri, 17 Sep 2010 16:40:15 -0700
> From: Kevin Buettner <kevinb@redhat.com>
> 
> On Fri, 17 Sep 2010 10:10:18 +0200 (CEST)
> Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> 
> > Obviously it is pointless to keep removing and reinserting these
> > breakpoints.  Perhaps they should be disabled as soon as one of them
> > has been hit?
> 
> That sounds like a good idea.  It's not sufficient though for
> debugging scenarios in which one attaches to a program that's
> already gone past start or main.  Perhaps we should skip the
> attempt to place a breakpoint on _start, __start, and main
> when attaching?

Probably.  We attempt to read the list of shared libraries when we
attach, and I'd be impressed if somebody would be able to attach to a
process before it hits _start ;).