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.
+2018-04-07 Simon Marchi <simon.marchi@polymtl.ca>
+
+ * progspace.c (clone_program_space): Pass SYMFILE_DEFER_BP_RESET
+ to symbol_file_add_main.
+
2018-04-07 Simon Marchi <simon.marchi@polymtl.ca>
PR mi/22299
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;
}