[PATCH] Defer breakpoint reset when cloning progspace for fork child

[Simon Marchi]

On 2018-03-30 15:01, Simon Marchi wrote:
> 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.

I pushed this patch.

Simon