public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: gdb-patches@sourceware.org
Cc: Simon Marchi <simon.marchi@polymtl.ca>
Subject: [PATCH] Defer breakpoint reset when cloning progspace for fork child
Date: Fri, 30 Mar 2018 19:01:00 -0000	[thread overview]
Message-ID: <20180330190132.20823-1-simon.marchi@polymtl.ca> (raw)

Using this simple test:

  static void
  break_here ()
  {
  }

  int
  main (int argc, char *argv[])
  {
    fork ();
    break_here();
    return 0;
  }

compiled as a PIE:

  $ gcc test.c -g3 -O0 -o test -pie

and running this:

  $ ./gdb -nx -q --data-directory=data-directory ./test -ex "b break_here" -ex "set detach-on-fork off" -ex r

gives:

  Warning:
  Cannot insert breakpoint 1.
  Cannot access memory at address 0x64a

Note that GDB might get stopped by SIGTTOU because of this issue:

  https://sourceware.org/bugzilla/show_bug.cgi?id=23020

In that case, just use "fg" to continue.

This issue happens only with position-independent executables.  Adding
the main objfile for the new inferior (the fork child) causes GDB to try
to reset the breakpoints.  However, that new objfile has not been
relocated yet.  So the breakpoint on "break_here" resolves to an
unrelocated address, from which we are trying to read/write to set a
breakpoint.  Passing SYMFILE_DEFER_BP_RESET avoids that problem.  The
executable is relocated just after, in the follow_fork_inferior
function.

The buildbot seems happy with this patch.  I don't think it's necessary
to add a new test.  Just changing this made many tests go from FAIL to
PASS on my machine, where gcc produces PIE executables by default.  If
anything, I think we would need to add a board file that produces
position-independent executables, so that we can run all the tests with
PIE, even on machines where that is not the default.

gdb/ChangeLog:

	* progspace.c (clone_program_space): Pass SYMFILE_DEFER_BP_RESET
	to symbol_file_add_main.
---
 gdb/progspace.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gdb/progspace.c b/gdb/progspace.c
index e0bcc5a18d68..ba400d47aa5c 100644
--- a/gdb/progspace.c
+++ b/gdb/progspace.c
@@ -166,7 +166,8 @@ clone_program_space (struct program_space *dest, struct program_space *src)
     exec_file_attach (src->pspace_exec_filename, 0);
 
   if (src->symfile_object_file != NULL)
-    symbol_file_add_main (objfile_name (src->symfile_object_file), 0);
+    symbol_file_add_main (objfile_name (src->symfile_object_file),
+			  SYMFILE_DEFER_BP_RESET);
 
   return dest;
 }
-- 
2.16.3

             reply	other threads:[~2018-03-30 19:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-30 19:01 Simon Marchi [this message]
2018-04-07 17:52 ` Simon Marchi
2018-04-07 18:43   ` Pedro Alves
2018-04-09 19:10     ` Simon Marchi
2018-04-09 19:21       ` Pedro Alves
2018-04-09 19:35         ` Simon Marchi

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=20180330190132.20823-1-simon.marchi@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).