From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 369BE3857C43 for ; Fri, 27 Oct 2023 13:56:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 369BE3857C43 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 369BE3857C43 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698415020; cv=none; b=wzSInlMEWOrGXc+dIgNttM6y5vGvmvxMUL5cJm5Ca4xbgHOwP3eL/RHzlJM31yaeUNLClsCyI789wY465/GtwR6suRINCmLjuKrTgGsAamf9bWUj72qERvXpTGRYFKxF5cPMTPtvrlPHK0odfgVe5+OI0krDY17BfesJCcWqNTA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698415020; c=relaxed/simple; bh=mSPiygNOPSEFpzpDf5P5YEEkZM/aGu6r4T2SPOGx3a0=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=mfGLO/F6QuZx8j54liQmSB5ZBa8cPi1U27CIPTmnomy5yC43QchTMZwVD2spDhXt3usucSgl++wKuPNNG39tWjuVB/bAPY+JVDX+vrLzXt/2EuCVH1x/bJ8ml8y7yjgT6TOdSvD55tUGjhkEGg2LX3Kkh58Q/oqBUhX46/xIUkg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1698415017; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PTJn+cRw2/V9vD7Qk6RfvlrXErfJqwt2dBQLfLuhbRA=; b=MCf0iArNIKpuGfNN5NH+1QcXGVzNGznmnMhxJj0DbuJI7EPkhaizHax/RXVTey6RXnsFeO ooSxKYdvEitVfve2FFh5E7CO5QfyREHbEcHxe/BscoAd/BsmruIhD6XNjpHglfYE8wjolP nPcX45tHD4njsgkTul2iLU86p/yA3ds= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-517-QkGs7Ve_NoWxNvZrghvOeA-1; Fri, 27 Oct 2023 09:56:56 -0400 X-MC-Unique: QkGs7Ve_NoWxNvZrghvOeA-1 Received: by mail-qt1-f200.google.com with SMTP id d75a77b69052e-41cb4d6744bso26901371cf.0 for ; Fri, 27 Oct 2023 06:56:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698415015; x=1699019815; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PTJn+cRw2/V9vD7Qk6RfvlrXErfJqwt2dBQLfLuhbRA=; b=HgVlujgP7QzaZQqpxwj+enp2yG7IQgAaSFlzVTBqo0REYI/Z/3PD8f22Z43NhfYq3d XjTFqHfLbdGYrlEzPVQdy2uRxXb7lkIZz3LxZrhY4h5BaTHmcn0Kf/tt1OQ0bg+gpPYP NxVTCEDk18QrWtw246vRubu/hFxx74YziJ6LpRhSB444wVOEM+SGc6g3feZ8CsvTUESU y/cwqWz5auenAYdQ1E3I1FH6CGk3+RZlgvzF7LS0vUtl4uGR4IYut9KuGFcMNMAa9mhY jyUUXivvx316MMtrB+v9ZCQuCFTwCRwbVkZqEepHbXUKIVi6wZ+0TbM1sp1dtQY2Xj5H HYRQ== X-Gm-Message-State: AOJu0Yzo/TH62y/jHylPKPGsfzQ3dymtUv4ipgqGFFyGdzbmUpLYRVtc mMjeJUhJ6CFfP4Z9YAZ8oo1Tp+XC69trJOZyAZMmlsAaUVpG/w7BPTsvNBre7A335A9XseYPbA4 X51sudcpzCdadrlylOrFCkoOpEQwUeg== X-Received: by 2002:a05:622a:1113:b0:41e:1f5d:7009 with SMTP id e19-20020a05622a111300b0041e1f5d7009mr2894437qty.25.1698415015447; Fri, 27 Oct 2023 06:56:55 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEHyYfh6wZlybQaIc0PLqfaoFPJlZQGrlKO8CKyeBHKXb2Ols1koxA+rHuLxgQ1i1+njp1HtA== X-Received: by 2002:a05:622a:1113:b0:41e:1f5d:7009 with SMTP id e19-20020a05622a111300b0041e1f5d7009mr2894417qty.25.1698415015009; Fri, 27 Oct 2023 06:56:55 -0700 (PDT) Received: from localhost ([31.111.84.209]) by smtp.gmail.com with ESMTPSA id l15-20020ac84ccf000000b004198ae7f841sm593105qtv.90.2023.10.27.06.56.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Oct 2023 06:56:54 -0700 (PDT) From: Andrew Burgess To: Guinevere Larsen , gdb-patches@sourceware.org Cc: Guinevere Larsen Subject: Re: [PATCH] gdb/testsuite: Work around clang fails in gdb.base/watchpoint.exp In-Reply-To: <20231026090448.1182959-1-blarsen@redhat.com> References: <20231026090448.1182959-1-blarsen@redhat.com> Date: Fri, 27 Oct 2023 14:56:52 +0100 Message-ID: <8734xw2mor.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Guinevere Larsen writes: > as mentioned in commit def86538a46f7ce6fbb215cfb184e23015b5d538, clang > doesn't use the CFA information for variable locations, making it so > software watchpoints get false hits when exiting a function. Differently > to that commit, however, gdb.base/watchpoint.exp also needs to be > explicitly continued so the inferior will remain in sync with what the > exp file expects, so this commit uses gdb_test_multiple to identify that > situation. > > I also chose to keep the test passing in that scenario because the GDB > feature being tested, software watchpoints, is working as expected. I'm not sure I 100% agree with this conclusion. The test is placing on a watchpoint that isn't expected to change ... yet we see the watchpoint trigger. I'd say the test is failing. I wonder if we could just set a flag when we see an unexpected stop, and then xfail rather than pass once the watchpoint goes out of scope? I think the right fix would be to implement the gdbarch_stack_frame_destroyed_p method for amd64. Looking in amd64-tdep.c I noticed we actually already have amd64_stack_frame_destroyed_p, we just don't register it with the gdbarch ... I guess there's some history here. Anyway, the patch below (untested except for watchpoint.exp) seems to remove the need for any changes to watchpoint.exp, what are your thoughts? > --- > gdb/testsuite/gdb.base/watchpoint.exp | 82 +++++++++++++++++++++++++-- > 1 file changed, 76 insertions(+), 6 deletions(-) > > diff --git a/gdb/testsuite/gdb.base/watchpoint.exp b/gdb/testsuite/gdb.base/watchpoint.exp > index 70864655c6d..5d8d6b9cb31 100644 > --- a/gdb/testsuite/gdb.base/watchpoint.exp > +++ b/gdb/testsuite/gdb.base/watchpoint.exp > @@ -30,6 +30,11 @@ if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {deb > return -1 > } > > +set using_clang 0 > +if {[test_compiler_info "clang-*"]} { > + set using_clang 1 > +} You can actually use 'true' and 'false' here, given this is a boolean. > + > # True if we're forcing no hardware watchpoints. > set no_hw 0 > > @@ -486,6 +491,20 @@ proc test_complex_watchpoint {} { > } > fail $test > } > + -re -wrap ".*Continuing.*\[Ww\]atchpoint.*" { > + global no_hw > + global using_clang > + # Clang doesn't use the CFA, so software watchpoints get one > + # false hit here. Detect if we're in that situation and > + # ignore the false hit. For more info, see: > + # https://github.com/llvm/llvm-project/issues/64390 > + if {$using_clang == 1 && $no_hw == 1} { And here (and elsewhere) you can write: if {$using_clang && $no_hw} { which better reflects the boolean nature of these flags. > + send_gdb "cont\n" > + exp_continue > + } else { > + fail $gdb_test_name > + } > + } > } > > gdb_continue_to_breakpoint "func2 breakpoint here, second time" > @@ -501,8 +520,25 @@ proc test_complex_watchpoint {} { > "trigger1 partially local watch" > gdb_test "cont" "Continuing.*\[Ww\]atchpoint .*: local_a . ival5.*" \ > "trigger2 partially local watch" > - gdb_test "cont" "Continuing.*\[Ww\]atchpoint .* deleted because the program has left the block in.*which its expression is valid.*" \ > - "self-delete partially local watch" > + gdb_test_multiple "cont" "self-delete partially local watch" { > + -re -wrap "Continuing.*\[Ww\]atchpoint .* deleted because the program has left the block in.*which its expression is valid.*" { > + pass $gdb_test_name > + } > + -re -wrap ".*Continuing.*\[Ww\]atchpoint.*" { > + global no_hw > + global using_clang > + # Clang doesn't use the CFA, so software watchpoints get one > + # false hit here. Detect if we're in that situation and > + # ignore the false hit. For more info, see: > + # https://github.com/llvm/llvm-project/issues/64390 > + if {$using_clang == 1 && $no_hw == 1} { > + send_gdb "cont\n" > + exp_continue > + } else { > + fail $gdb_test_name > + } > + } > + } > > # We should be in "func2" again now. Test a watch of a > # static (non-stack-based) local. Since this has scope > @@ -535,8 +571,25 @@ proc test_complex_watchpoint {} { > "set local watch in recursive call" > gdb_test "cont" "Continuing.*\[Ww\]atchpoint .*: local_x.*New value = 2.*" \ > "trigger local watch in recursive call" > - gdb_test "cont" "Continuing.*\[Ww\]atchpoint .* deleted because the program has left the block in.*which its expression is valid.*" \ > - "self-delete local watch in recursive call" > + gdb_test_multiple "cont" "self-delete local watch in recursive call" { > + -re -wrap "Continuing.*\[Ww\]atchpoint .* deleted because the program has left the block in.*which its expression is valid.*" { > + pass $gdb_test_name > + } > + -re -wrap ".*Continuing.*\[Ww\]atchpoint.*" { > + global no_hw > + global using_clang > + # Clang doesn't use the CFA, so software watchpoints get one > + # false hit here. Detect if we're in that situation and > + # ignore the false hit. For more info, see: > + # https://github.com/llvm/llvm-project/issues/64390 > + if {$using_clang == 1 && $no_hw == 1} { > + send_gdb "cont\n" > + exp_continue > + } else { > + fail $gdb_test_name > + } > + } > + } > } > > # Repeat the preceding test, but this time use "recurser::local_x" as > @@ -551,8 +604,25 @@ proc test_complex_watchpoint {} { > "set local watch in recursive call with explicit scope" > gdb_test "cont" "Continuing.*\[Ww\]atchpoint .*: recurser::local_x.*New value = 2.*" \ > "trigger local watch with explicit scope in recursive call" > - gdb_test "cont" "Continuing.*\[Ww\]atchpoint .* deleted because the program has left the block in.*which its expression is valid.*" \ > - "self-delete local watch with explicit scope in recursive call (2)" > + gdb_test_multiple "cont" "self-delete local watch with explicit scope in recursive call (2)" { > + -re -wrap "Continuing.*\[Ww\]atchpoint .* deleted because the program has left the block in.*which its expression is valid.*" { > + pass $gdb_test_name > + } > + -re -wrap ".*Continuing.*\[Ww\]atchpoint.*" { > + global no_hw > + global using_clang > + # Clang doesn't use the CFA, so software watchpoints get one > + # false hit here. Detect if we're in that situation and > + # ignore the false hit. For more info, see: > + # https://github.com/llvm/llvm-project/issues/64390 > + if {$using_clang == 1 && $no_hw == 1} { > + send_gdb "cont\n" > + exp_continue > + } else { > + fail $gdb_test_name > + } > + } > + } > } > > # Disable everything so we can finish the program at full speed > -- > 2.41.0 Thanks, Andrew --- diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c index e6feee677b3..15120d55976 100644 --- a/gdb/amd64-tdep.c +++ b/gdb/amd64-tdep.c @@ -2888,7 +2888,7 @@ static const struct frame_base amd64_frame_base = /* Normal frames, but in a function epilogue. */ -/* Implement the stack_frame_destroyed_p gdbarch method. +/* Implement core of the stack_frame_destroyed_p gdbarch method. The epilogue is defined here as the 'ret' instruction, which will follow any instruction such as 'leave' or 'pop %ebp' that destroys @@ -2908,6 +2908,33 @@ amd64_stack_frame_destroyed_p (struct gdbarch *gdbarch, CORE_ADDR pc) return 1; } +/* Implement the gdbarch_stack_frame_destroyed_p method. + + This wrapper delegates to amd64_stack_frame_destroyed_p_1 for compilers + that we know get the debug information for stack local variables wrong + (i.e. Clang) during the function epilogue. + + For other compilers (i.e. not Clang) we trust the debug information. */ + +static int +amd64_stack_frame_destroyed_p_1 (struct gdbarch *gdbarch, CORE_ADDR pc) +{ + struct compunit_symtab *cust = find_pc_compunit_symtab (pc); + + /* LLVM backend (Clang/Flang) doesn't use CFA based locations for stack + local variables. As a consequence, when we enter the function + epilogue GDB will calculate the wrong location for stack local + variables, and watchpoints will trigger. */ + if (cust != nullptr + && cust->producer () != nullptr + && producer_is_llvm (cust->producer ())) + return amd64_stack_frame_destroyed_p_1 (gdbarch, pc); + + /* For other producers, trust the debug information. */ + return 0; +} + + static int amd64_epilogue_frame_sniffer_1 (const struct frame_unwind *self, frame_info_ptr this_frame, @@ -2938,7 +2965,7 @@ amd64_epilogue_frame_sniffer_1 (const struct frame_unwind *self, } /* Check whether we're in an epilogue. */ - return amd64_stack_frame_destroyed_p (gdbarch, pc); + return amd64_stack_frame_destroyed_p_1 (gdbarch, pc); } static int @@ -3310,6 +3337,8 @@ amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch, set_gdbarch_gen_return_address (gdbarch, amd64_gen_return_address); + set_gdbarch_stack_frame_destroyed_p (gdbarch, amd64_stack_frame_destroyed_p); + /* SystemTap variables and functions. */ set_gdbarch_stap_integer_prefixes (gdbarch, stap_integer_prefixes); set_gdbarch_stap_register_prefixes (gdbarch, stap_register_prefixes);