From: Guinevere Larsen <guinevere@redhat.com>
To: Keith Seitz <keiths@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb/testsuite: rework bp-cond-failure to not depend on inlining
Date: Fri, 20 Sep 2024 13:20:30 -0300 [thread overview]
Message-ID: <eeca0cf3-9db2-4830-b2bc-41259078c0f5@redhat.com> (raw)
In-Reply-To: <b2dc4ddd-d343-40d5-921b-0b41f46a6650@redhat.com>
On 9/20/24 12:58 PM, Keith Seitz wrote:
> On 9/20/24 8:56 AM, Guinevere Larsen wrote:
>> On 9/20/24 12:35 PM, Keith Seitz wrote:
>>>
>>> For the casual visitor to this file that has often been burned by
>>> hard-coded line numbers or locations, it would, at least, save me some
>>> grief.
>> At the top of the exp file, the comment that explains the purpose of
>> the test ends with the following:
>>
>> # We check that the correct breakpoint number appears in the error
>> # message, and that the error is reported at the correct source
>> # location.
>>
>> Would you still like me to add the comment in context, or do you
>> think that is enough?
>
> Okay, fully optional now, but please consider adding a comment referring
> to that explanation, at least. Again, I missed it entirely. :-)
I've given some more thought and I think a couple of comments could help
anyway. Here's my suggestion, thought?
diff --git a/gdb/testsuite/gdb.base/bp-cond-failure.exp
b/gdb/testsuite/gdb.base/bp-cond-failure.exp
index 403e7db9032..b4c046c4bd6 100644
--- a/gdb/testsuite/gdb.base/bp-cond-failure.exp
+++ b/gdb/testsuite/gdb.base/bp-cond-failure.exp
@@ -57,9 +57,18 @@ proc run_test { cond_eval access_type bpexpr nloc } {
# Setup the conditional breakpoint and record its number.
gdb_breakpoint "${bpexpr} if (*(${access_type} *) 0) == 0"
+
+ # This test aims to test that GDB displays the correct breakpoint
number
+ # and location when there is an error testing a breakpoint condition,
+ # so it is important to hardcode the breakpoint number into the regex,
+ # along with the location, if applicable.
set bp_num [get_integer_valueof "\$bpnum" "*UNKNOWN*"]
if { $nloc > 1 } {
+ # We hardcode location 2 because, for some reason, Clang will always
+ # order the debug information so we hit the second location. For
+ # simplicity the .c is ordered in such a way that GCC will also
order
+ # the debug info to have us land on location 2.
gdb_test "continue" \
[multi_line \
"Continuing\\." \
--
Cheers,
Guinevere Larsen
She/Her/Hers
>
> Keith
>
next prev parent reply other threads:[~2024-09-20 16:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-19 12:42 Guinevere Larsen
2024-09-20 15:35 ` Keith Seitz
2024-09-20 15:56 ` Guinevere Larsen
2024-09-20 15:58 ` Keith Seitz
2024-09-20 16:20 ` Guinevere Larsen [this message]
2024-09-20 16:45 ` Keith Seitz
2024-09-20 18:55 ` Tom Tromey
2024-09-20 19:11 ` Guinevere Larsen
2024-09-23 7:46 ` Aktemur, Tankut Baris
2024-09-23 10:40 ` Andrew Burgess
2024-09-23 12:24 ` Aktemur, Tankut Baris
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=eeca0cf3-9db2-4830-b2bc-41259078c0f5@redhat.com \
--to=guinevere@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=keiths@redhat.com \
/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