public inbox for gdb-testers@sourceware.org help / color / mirror / Atom feed
From: sergiodj+buildbot@sergiodj.net To: gdb-testers@sourceware.org Subject: [binutils-gdb] Defer breakpoint reset when cloning progspace for fork child Date: Sat, 07 Apr 2018 18:47:00 -0000 [thread overview] Message-ID: <b2e586e850dbf1dafc10beea3250d22e70add4b5@gdb-build> (raw) *** TEST RESULTS FOR COMMIT b2e586e850dbf1dafc10beea3250d22e70add4b5 *** Author: Simon Marchi <simon.marchi@polymtl.ca> Branch: master Commit: b2e586e850dbf1dafc10beea3250d22e70add4b5 Defer breakpoint reset when cloning progspace for fork child 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.
next reply other threads:[~2018-04-07 18:47 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-07 18:47 sergiodj+buildbot [this message] 2018-04-07 18:47 ` Failures on RHEL-s390x-m64, branch master sergiodj+buildbot 2018-04-07 20:05 ` Failures on Fedora-s390x-m64, " sergiodj+buildbot 2018-04-07 22:11 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot 2018-04-07 22:15 ` Failures on Fedora-i686, " sergiodj+buildbot 2018-04-07 22:25 ` Failures on Debian-s390x-m64, " sergiodj+buildbot 2018-04-07 22:27 ` Failures on Fedora-x86_64-m32, " sergiodj+buildbot 2018-04-08 0:28 ` Failures on Ubuntu-AArch32-native-extended-gdbserver-m32, " sergiodj+buildbot 2018-04-08 0:55 ` Failures on Ubuntu-AArch32-native-gdbserver-m32, " sergiodj+buildbot 2018-04-08 1:21 ` Failures on Ubuntu-AArch32-m32, " sergiodj+buildbot
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=b2e586e850dbf1dafc10beea3250d22e70add4b5@gdb-build \ --to=sergiodj+buildbot@sergiodj.net \ --cc=gdb-testers@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: linkBe 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).