From patchwork Fri Dec 29 09:26:58 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 82985 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 711383858C60 for ; Fri, 29 Dec 2023 09:32:55 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org 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 9EE013858C36 for ; Fri, 29 Dec 2023 09:27:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9EE013858C36 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 9EE013858C36 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=1703842049; cv=none; b=LyU3HLoS6YeWuzvAecPtYhWMlQd6SNgP8coFa3wSMzqtd5tUAjy4Ug7tf/IBjdb2MoJR3d6azxCUHHD2UQSk6XZzvI5x8dTxNJaDLoFIkE4ld1P0PS1D3peHI/Ql7QYEbaeTOMqhDD6eQcFDnAiJ7P2Vvjo0uS13s7krEan5A5g= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703842049; c=relaxed/simple; bh=wdlfFASxshji10sdDnvSYKasMleMHubTYIkwr8/LsXg=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=b2EQ/f6m7bGEnwsOIzk1520lJ18KPDXfWsMVuDeiQ0gQ8kfiWf5NyqNdKnTkWQqKKm+BRxYkD3vIqhIWZ5L1JR702BQDLtQVr5pD9FIV4Y0vfIS+SGI0oiqydcU8kjXDfGbCf6/HGWXdYuQKCBxwyU0uvkhkX8mCrpG0duTpm3A= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1703842042; 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=PkAPKwYIcyWChaS2kGAl4S0uua/Mdxz4SWL3VB1dFdk=; b=cKbyoVnwR8xZapbuw2qtyJXa3dbyJ1NQ7BKuR8d6/ZQlk8jK8T9RW5llTzcqmmlXeuW/nd Lcxm1eULKKOcBccw5aHYDukhhRaMt+n72AiDGHhG1K8CXBrvg0w8AJTnKYruWCRnz1Kuzt dpPdH7K7mlhtO+3lmD0szj62Y5MHWEI= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-183-7qgT0oFCNhCR7r4oP1l6yA-1; Fri, 29 Dec 2023 04:27:20 -0500 X-MC-Unique: 7qgT0oFCNhCR7r4oP1l6yA-1 Received: by mail-lf1-f70.google.com with SMTP id 2adb3069b0e04-50e8b421301so1054988e87.2 for ; Fri, 29 Dec 2023 01:27:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703842038; x=1704446838; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PkAPKwYIcyWChaS2kGAl4S0uua/Mdxz4SWL3VB1dFdk=; b=jYeQGG0yV3dlL1kSpxa00BS3wbsbhSSS1DtHJzTWRZTbPWQLdXhwhuvQcjJLCrLirc vQ2muS4ISsNPOkM3JNcrYgPYfndT41MTu1/zN7aIYrJs7qUYQ00ryD4ccBp38pwQajPU mWVOZHZLT7Z/dqR/vpEryjw2Y+TZ30OVM8bLmrsu4VyBjqY/lLbMmQHqesa+FWFwLXzy kLMOvYm5EJW3B/i5Rb47sd+3Q9pJ7SqgEc3I4YN7g+jnrcqN4hTEB7RZBB4wTDqYCREA sxRnTLhV8YN6uaEhqVn+S47zQwNmIozcAxkeISN3qOt5MV5sKYagxfAy0zYoMZO8IgZs zMTQ== X-Gm-Message-State: AOJu0YyOZIEzgDC/f7x2j/3SIGajDx1/tkJRTT0Yi2f1xVEfB5Z4DkEj E1FysjcQ3W7RWwq0RTZo4yA1NHdzDN615vC0vz96JPu70oywL58JzztZICjD7nqp3SGMpWcIz4h rQQsc7k5vBmXHxYsZspMIrcgNdbHuD/CySrxwU6xv12yqrhaqaRyGk6SyVuBODXKeppW+U1Pl8V LZkIh5wc+nc6zznQ== X-Received: by 2002:a05:6512:10d5:b0:50e:80fe:add8 with SMTP id k21-20020a05651210d500b0050e80feadd8mr2116931lfg.41.1703842037961; Fri, 29 Dec 2023 01:27:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IFZsitUEkIH8lI1O6ziloszVg9Ee8lfrFQfVmP0RB2xEY0z7rtXC6V+6QLEygmyAWc62yPT4A== X-Received: by 2002:a05:6512:10d5:b0:50e:80fe:add8 with SMTP id k21-20020a05651210d500b0050e80feadd8mr2116924lfg.41.1703842037552; Fri, 29 Dec 2023 01:27:17 -0800 (PST) Received: from localhost ([2a00:23c7:c696:e701:85a5:8a0c:1403:2dc]) by smtp.gmail.com with ESMTPSA id k4-20020a5d5244000000b003368c8d120fsm17524345wrc.7.2023.12.29.01.27.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Dec 2023 01:27:16 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv8 03/14] gdb: change 'if' to gdb_assert in update_dprintf_command_list Date: Fri, 29 Dec 2023 09:26:58 +0000 Message-Id: <5b7329490d4871ae97a6341792560d5d452c3f79.1703841366.git.aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-13.1 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, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org I noticed in update_dprintf_command_list that we handle the case where the bp_dprintf style breakpoint doesn't have a format and args string. However, I don't believe such a situation is possible. The obvious approach certainly already catches this case: (gdb) dprintf main Format string required If it is possible to create a dprintf breakpoint without a format and args string then I think we should be catching this case and handling it at creation time, rather than having GDB just ignore the situation later on. And so, I propose that we change the 'if' that ignores the case where the format/args string is empty, and instead assert that we do always have a format/args string. The original code, that handled an empty format/args string has existed since commit e7e0cddfb0d4, which is when dprintf support was added to GDB. If I'm correct and this situation can't ever happen then there should be no user visible changes after this commit. --- gdb/breakpoint.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c index 3ba3d0d3d12..48c44ea27cc 100644 --- a/gdb/breakpoint.c +++ b/gdb/breakpoint.c @@ -8538,8 +8538,9 @@ update_dprintf_command_list (struct breakpoint *b) const char *dprintf_args = b->extra_string.get (); gdb::unique_xmalloc_ptr printf_line = nullptr; - if (!dprintf_args) - return; + /* Trying to create a dprintf breakpoint without a format and args + string should be detected at creation time. */ + gdb_assert (dprintf_args != nullptr); dprintf_args = skip_spaces (dprintf_args);