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.133.124]) by sourceware.org (Postfix) with ESMTPS id 74FCD3858CDA for ; Mon, 22 Apr 2024 18:40:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 74FCD3858CDA 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 74FCD3858CDA Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713811223; cv=none; b=FsMN1Z+PM/1q01w+5S4xHO/02kNlpbFSc5y4AEPi6UjL+HFHhztaqnYDxCmOZRgi6GaXGCxzgurfuiiMJRKUCES+bkVO5e4k+Z5Jnv+3FsCNqMrfk4YaYXlxahnqK+aq4YJeLZMhLhqtqBf88c7P6PsSUNl6jYtXzSdj1jr9NTc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713811223; c=relaxed/simple; bh=6rVBTqL5qkptE9WyzvtosnoHEUEWMXhNb1JM0KBX/hk=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=qRBxQxEXoTlzb5PztHwiNSSp0+Wo1mmhujlccizSdxz7ObUHce4lhzrZajCzUa/eKcP0u5+QUsLCv2IO515bdj54QkGS6v9FEY2+Wj3XsmFegdDPIDoERhF4gHDvvFtgZhyqoFABRHO+yPIRUrs7OvcsWzNtwDMdNP+AWMAgIYY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1713811222; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uJHSpoiCBL/kNzssdUeuZ4UYmGCBuPFCy59otZYACqI=; b=MmYDjC03Gg8WLAdzKUGmhrFgW1uQw4V1+byy2myWjL7ovGDdCw/iNeHz5A646b3ObOlQKz tJSoCV0pZbSpjdUESQ0QIrWZCAuh1iZF8Bj87RSJ+Wjrt41sRIL3Ape/QjsFtLb0DRtyim zG54DoP8YKIOgmdtx+JS2qS5h9Ja0G0= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-186-cXsOkfw_NwWYeMUJCS-7xA-1; Mon, 22 Apr 2024 14:40:19 -0400 X-MC-Unique: cXsOkfw_NwWYeMUJCS-7xA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 790D8104B501; Mon, 22 Apr 2024 18:40:19 +0000 (UTC) Received: from f39-zbm-amd (unknown [10.22.16.14]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 35E51C01595; Mon, 22 Apr 2024 18:40:19 +0000 (UTC) Date: Mon, 22 Apr 2024 11:40:17 -0700 From: Kevin Buettner To: Thiago Jung Bauermann Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 2/2] gdb/testsuite: Add gdb.base/memops-watchpoint.exp Message-ID: <20240422114017.64cf2adb@f39-zbm-amd> In-Reply-To: <87wmoq2qid.fsf@linaro.org> References: <20240420213307.976401-1-thiago.bauermann@linaro.org> <20240420213307.976401-3-thiago.bauermann@linaro.org> <20240421142019.0f6d75d0@f39-zbm-amd> <87wmoq2qid.fsf@linaro.org> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: On Sun, 21 Apr 2024 21:24:42 -0300 Thiago Jung Bauermann wrote: > >> +require libc_has_debug_info > > > > I'm wondering about the need for this requirement. When I comment it > > out and run it on a machine without libc debuginfo, I do see 3 FAILs, > > but it seems to me that those could be turned into PASSes by changing > > the regular expressions for the "continue until..." tests. [...] > > I added the requirement because in my aarch64-linux system without libc6 > debug info I get: > > continue > Continuing. > > Hardware watchpoint 2: -location a[28] > > Old value = 104 'h' > New value = 0 '\000' > 0x0000fffff7e90664 in ?? () from /lib/aarch64-linux-gnu/libc.so.6 > (gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits > > And I just tested removing libc6-dbg from my x86_64-linux laptop: > > continue > Continuing. > > Hardware watchpoint 2: -location a[28] > > Old value = 104 'h' > New value = 0 '\000' > 0x00007ffff7d8e05f in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > (gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits > > So it depends on the system. What distro are you using? > One alternative would be to not use the require statement and run the > test until the watchpoint hits, and have a case in gdb_test_multiple to > mark as UNRESOLVED if the function name is '??'. I'm in favor of this approach. If we stick with the require statement, I think that Fedora testing will frequently show this new test as unsupported since installing debuginfo is less common / important that it used to be. (This is due to debuginfod doing it for you. But I think that debuginfod is mostly disabled when running the GDB tests.)