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] Fix resolving GNU ifunc bp locations when inferior runs resolver Date: Thu, 26 Apr 2018 19:45:00 -0000 [thread overview] Message-ID: <79188d8d27a8885aee2ca4ff55238219a6aa7228@gdb-build> (raw) *** TEST RESULTS FOR COMMIT 79188d8d27a8885aee2ca4ff55238219a6aa7228 *** Author: Pedro Alves <palves@redhat.com> Branch: master Commit: 79188d8d27a8885aee2ca4ff55238219a6aa7228 Fix resolving GNU ifunc bp locations when inferior runs resolver I noticed that if you set a breakpoint on an ifunc before the ifunc is resolved, and then let the program call the ifunc, thus resolving it, GDB end up with a location for that original breakpoint that is pointing to the ifunc target, but it is left pointing to the first address of the function, instead of after its prologue. After prologue is what you get if you create a new breakpoint at that point. 1) With no debug info for the target function: 1.a) Set before resolving, and then program continued passed resolving: Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000000400753 <final> 1.b) Breakpoint set after inferior resolved ifunc: Num Type Disp Enb Address What 2 breakpoint keep y 0x0000000000400757 <final+4> 2) With debug info for the target function: 1.a) Set before resolving, and then program continued passed resolving: Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000000400753 in final at gdb/testsuite/gdb.base/gnu-ifunc-final.c:20 1.b) Breakpoint set after inferior resolved ifunc: Num Type Disp Enb Address What 2 breakpoint keep y 0x000000000040075a in final at gdb/testsuite/gdb.base/gnu-ifunc-final.c:21 The problem is that elf_gnu_ifunc_resolver_return_stop (called by the internal breakpoint that traps the resolver returning) does not agree with linespec.c:minsym_found. It does not skip to the function's start line (i.e., past the prologue). We can now use the find_function_start_sal overload added by the previous commmit to fix this. New tests included, which fail before the patch, and pass afterwards. gdb/ChangeLog: 2018-04-26 Pedro Alves <palves@redhat.com> * elfread.c (elf_gnu_ifunc_resolver_return_stop): Use find_function_start_sal instead of find_pc_line. gdb/testsuite/ChangeLog: 2018-04-26 Pedro Alves <palves@redhat.com> * gdb.base/gnu-ifunc.exp (set-break): Test that GDB resolves ifunc breakpoint locations correctly of ifunc breakpoints set while the program resolves the ifunc.
next reply other threads:[~2018-04-26 19:37 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-26 19:45 sergiodj+buildbot [this message] 2018-04-26 19:37 ` Failures on Fedora-s390x-m64, branch master sergiodj+buildbot 2018-04-26 21:17 ` Failures on RHEL-s390x-m64, " sergiodj+buildbot 2018-04-27 2:58 ` Failures on Fedora-x86_64-m64, " sergiodj+buildbot 2018-04-27 2:59 ` Failures on Fedora-i686, " sergiodj+buildbot 2018-04-27 3:17 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot 2018-04-27 3:20 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " sergiodj+buildbot 2018-04-27 3:21 ` *** COMPILATION FAILED *** Failures on Fedora-x86_64-w64-mingw32, branch master *** BREAKAGE *** sergiodj+buildbot 2018-04-27 3:34 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, branch master sergiodj+buildbot 2018-04-27 4:02 ` Failures on Fedora-x86_64-cc-with-index, " sergiodj+buildbot 2018-04-27 10:13 ` Failures on Debian-s390x-m64, " sergiodj+buildbot 2018-04-27 10:33 ` Failures on Debian-s390x-native-gdbserver-m64, " sergiodj+buildbot 2018-04-28 22:52 ` Failures on Ubuntu-AArch32-native-extended-gdbserver-m32, " sergiodj+buildbot 2018-04-28 23:37 ` Failures on Ubuntu-AArch32-native-gdbserver-m32, " sergiodj+buildbot 2018-04-29 0:23 ` 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=79188d8d27a8885aee2ca4ff55238219a6aa7228@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).