Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sourceware.org
Subject: [RFC] solib-svr4.c: Never attempt to place breakpoints on _start, __start, or main
Date: Fri, 17 Sep 2010 02:13:00 -0000	[thread overview]
Message-ID: <20100916152334.7e4f1ee5@mesquite.lan> (raw)

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;
 }
 


             reply	other threads:[~2010-09-16 22:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-17  2:13 Kevin Buettner [this message]
2010-09-17  8:10 ` Daniel Jacobowitz
2010-09-17 12:29 ` Mark Kettenis
2010-09-18 14:13   ` Kevin Buettner
2010-09-18 16:03     ` Mark Kettenis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100916152334.7e4f1ee5@mesquite.lan \
    --to=kevinb@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox