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.


             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: 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).