public inbox for gdb-testers@sourceware.org help / color / mirror / Atom feed
From: sergiodj+buildbot@redhat.com To: gdb-testers@sourceware.org Subject: [binutils-gdb] Fix regression introduced in "break *<EXPR>" by explicit location patches. Date: Thu, 21 Jan 2016 10:33:00 -0000 [thread overview] Message-ID: <305e13e67faaf940ce6eb708847a655a0735a651@gdb-build> (raw) *** TEST RESULTS FOR COMMIT 305e13e67faaf940ce6eb708847a655a0735a651 *** Author: Joel Brobecker <brobecker@adacore.com> Branch: master Commit: 305e13e67faaf940ce6eb708847a655a0735a651 Fix regression introduced in "break *<EXPR>" by explicit location patches. A relatively recent patch support for explicit locations, and part of that patch cleaned up the way we parse breakpoint locations. Unfortunatly, a small regression crept in for "*<EXPR>" breakpoint locations. In particular, on PIE programs, one can see the issue by doing the following, with any program: (gdb) b *main Breakpoint 1 at 0x51a: file hello.c, line 3. (gdb) run Starting program: /[...]/hello Error in re-setting breakpoint 1: Warning: Cannot insert breakpoint 1. Cannot access memory at address 0x51a Warning: Cannot insert breakpoint 1. Cannot access memory at address 0x51a Just for the record, this regression was introduced by: commit a06efdd6effd149a1d392df8d62824e44872003a Date: Tue Aug 11 17:09:35 2015 -0700 Subject: Explicit locations: introduce address locations What happens is that the patch makes the implicit assumption that the address computed the first time is static, as if it was designed to only support litteral expressions (Eg. "*0x1234"). This allows the shortcut of not re-computing the breakpoint location's address when re-setting breakpoints. However, this does not work in general, as demonstrated in the example above. This patch plugs that hole simply by saving the original expression used to compute the address as part of the address location, so as to then re-evaluate that expression during breakpoint re-set. gdb/ChangeLog: * location.h (new_address_location): Add new parameters "addr_string" and "addr_string_len". (get_address_string_location): Add declaration. * location.c (new_address_location): Add new parameters "addr_string" and "addr_string_len". If not NULL, store a copy of the addr_string in the new location as well. (get_address_string_location): New function. (string_to_event_location): Update call to new_address_location. * linespec.c (event_location_to_sals) <ADDRESS_LOCATION>: Save the event location in the parser's state before passing it to convert_address_location_to_sals. * breakpoint.c (create_thread_event_breakpoint): Update call to new_address_location. (init_breakpoint_sal): Get the event location's string, if any, and use it to update call to new_address_location. * python/py-finishbreakpoint.c (bpfinishpy_init): Update call to new_address_location. * spu-tdep.c (spu_catch_start): Likewise. * config/djgpp/fnchange.lst: Add entries for gdb/testsuite/gdb.base/break-fun-addr1.c and gdb/testsuite/gdb.base/break-fun-addr2.c. gdb/testsuite/ChangeLog: * gdb.base/break-fun-addr.exp: New file. * gdb.base/break-fun-addr1.c: New file. * gdb.base/break-fun-addr2.c: New file.
next reply other threads:[~2016-01-21 10:33 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-01-21 10:33 sergiodj+buildbot [this message] 2016-01-21 10:33 ` Failures on RHEL-s390x-m64, branch master sergiodj+buildbot 2016-01-21 11:27 ` Failures on Fedora-x86_64-m32, " sergiodj+buildbot 2016-01-21 11:42 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " sergiodj+buildbot 2016-01-21 11:43 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot 2016-01-21 11:56 ` Failures on Fedora-x86_64-m64, " sergiodj+buildbot 2016-01-21 11:56 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot 2016-01-21 12:04 ` Failures on AIX-POWER7-plain, " sergiodj+buildbot 2016-01-21 13:14 ` Failures on Debian-s390x-native-gdbserver-m64, " sergiodj+buildbot 2016-01-21 13:57 ` Failures on Debian-s390x-native-extended-gdbserver-m64, " sergiodj+buildbot 2016-01-21 14:00 ` Failures on Debian-i686, " sergiodj+buildbot 2016-01-21 14:19 ` Failures on Debian-i686-native-gdbserver, " sergiodj+buildbot 2016-01-21 14:43 ` Failures on Debian-i686-native-extended-gdbserver, " sergiodj+buildbot 2016-01-21 15:34 ` Failures on Fedora-ppc64be-native-gdbserver-m64, " sergiodj+buildbot 2016-01-21 15:54 ` Failures on Fedora-ppc64be-native-extended-gdbserver-m64, " sergiodj+buildbot 2016-01-21 16:11 ` Failures on Fedora-ppc64le-native-extended-gdbserver-m64, " sergiodj+buildbot 2016-01-21 16:31 ` Failures on Fedora-ppc64le-cc-with-index, " sergiodj+buildbot 2016-01-21 16:47 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj+buildbot 2016-01-21 16:47 ` Failures on Fedora-ppc64le-m64, " sergiodj+buildbot 2016-01-21 18:04 ` Failures on Debian-x86_64-m64, " sergiodj+buildbot 2016-01-21 18:24 ` Failures on Debian-x86_64-native-gdbserver-m64, " 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=305e13e67faaf940ce6eb708847a655a0735a651@gdb-build \ --to=sergiodj+buildbot@redhat.com \ --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).