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] wrong line number in breakpoint location Date: Mon, 22 Jan 2018 04:32:00 -0000 [thread overview] Message-ID: <a9e408182d2faaed5c2457b68ea3276c719a590f@gdb-build> (raw) *** TEST RESULTS FOR COMMIT a9e408182d2faaed5c2457b68ea3276c719a590f *** Author: Joel Brobecker <brobecker@adacore.com> Branch: master Commit: a9e408182d2faaed5c2457b68ea3276c719a590f wrong line number in breakpoint location Consider the following situation, where we have one file containing... $ cat -n body.inc 1 i = i + 1; ... we include that file from some code, like so: $ cat -n cat -n small.c [...] 17 int 18 next (int i) 19 { 20 #include "body.inc" 21 return i; 22 } When trying to insert a breakpoint on line 18, for instance: (gdb) b small.c:18 Breakpoint 1 at 0x40049f: file body.inc, line 18. ^^ || Here, the issue is that GDB reports the breakpoint to be in file body.inc, which is true, but with the line number that corresponding to the user-requested location, which is not correct. Although the simple reproducer may look slightly artificial, the above is simply one way to reproduce the same issue observed when trying to insert a breakpoint on a function provided in a .h files and then subsequently inlined in a C file. What happens is the following: 1. We resolve the small.c:18 linespec into a symtab_and_line which has "small.c" and 18 as the symtab and line number. 2. Next, we call skip_prologue_sal, which calculates the PC past the prologue, and updates the symtab_and_line: PC, but also symtab (now body.inc) and the new line (now 1). 3. However, right after that, we do: /* Make sure the line matches the request, not what was found. */ intermediate_results.sals[i].line = val.line; We should either restore both symtab and line, or leave the actual line to match the actual symtab. This patch chose the latter. This introduces a few changes in a few tests, which required some updates, but looking at those change, I believe them to be expected. gdb/ChangeLog: * linespec.c (create_sals_line_offset): Remove code that preserved the symtab_and_line's line number. gdb/testsuite/ChangeLog: * gdb.base/break-include.c, gdb.base/break-include.inc, gdb.base/break-include.exp: New files. * gdb.base/ending-run.exp: Minor adaptations due to the breakpoint's line number now being the actual line number where the breakpoint was inserted. * gdb.mi/mi-break.exp: Likewise. * gdb.mi/mi-reverse.exp: Likewise. * gdb.mi/mi-simplerun.exp: Ditto. Tested on x86_64-linux.
next reply other threads:[~2018-01-22 4:32 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-01-22 4:32 sergiodj+buildbot [this message] 2018-01-22 4:31 ` Failures on RHEL-s390x-m64, branch master sergiodj+buildbot 2018-01-22 4:33 ` Failures on Debian-s390x-m64, " sergiodj+buildbot 2018-01-22 4:36 ` Failures on Fedora-i686, " sergiodj+buildbot 2018-01-22 4:48 ` Failures on Debian-s390x-native-extended-gdbserver-m64, " sergiodj+buildbot 2018-01-22 4:52 ` Failures on Ubuntu-AArch32-native-extended-gdbserver-m32, " sergiodj+buildbot 2018-01-22 4:56 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " sergiodj+buildbot 2018-01-22 5:00 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, " sergiodj+buildbot 2018-01-22 5:02 ` Failures on Debian-s390x-native-gdbserver-m64, " sergiodj+buildbot 2018-01-22 5:03 ` Failures on Fedora-x86_64-native-gdbserver-m64, " sergiodj+buildbot 2018-01-22 5:36 ` Failures on Ubuntu-AArch64-m64, " sergiodj+buildbot 2018-01-22 5:54 ` Failures on Ubuntu-AArch32-native-gdbserver-m32, " sergiodj+buildbot 2018-01-22 6:27 ` 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=a9e408182d2faaed5c2457b68ea3276c719a590f@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).