From patchwork Sat Dec 2 10:42:11 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 81184 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 956B93861873 for ; Sat, 2 Dec 2023 10:43:14 +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.133.124]) by sourceware.org (Postfix) with ESMTPS id 03929386184B for ; Sat, 2 Dec 2023 10:42:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 03929386184B 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 03929386184B 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=1701513756; cv=none; b=Q22xAkIBJLEOTUe+dM3yHJVCTAt2bV7/AFq1YkYoMX9KTJDqdeN3rH1jv0fvCXVRwpUILBbv5IUIxS8qGUhyzgPerCrlV4/qSWH9g06V3Rme8PVRKDcC9jEITZtDn//SUfQycO0giQHD7eBz7y/ndY1s29mxe3zPvQrt8cBLfH8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701513756; c=relaxed/simple; bh=EzzgWUoomtvtIZHknB2F5Bz+yCd9JusbmgLTktlUqd0=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=V5qVTN1c72OS4p46NlAtMQ2vXSNlcqh/3o4Jk0QbfYgd/LiEQfP+YiXPENHm1GPklJPWDkPAxoDVQd5wznj+XwpnDncWUC7LANVs6kfjoKhL6A+8zEhUrgpv0E0Adiini/L1cSqETFp8Fr8lqWsZj6OZEKoldwNnkBrrIw/rFFI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701513753; 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=+I6MLsJiDM3URhb+RbXbP5Ake1sH71it2g3WR1sCNEg=; b=U29jP7uAsLr346p/zWAeNYT7au7WdMryx5Bqc/1JGCu+NF2ul8ca15ACdaiwrITaun5lfO 9WuPxIXqmdbD795zj9CrY9okgiqRvmuXC+KlW/CC/vCyfZ1Rs+FjGLJ/lOccHaz7KzpLwq H3tKxei++N/Dge7SvmFZtc+uwMJ2u78= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-28-gcqTH6RZM8282s3_hlY4jA-1; Sat, 02 Dec 2023 05:42:32 -0500 X-MC-Unique: gcqTH6RZM8282s3_hlY4jA-1 Received: by mail-ed1-f72.google.com with SMTP id 4fb4d7f45d1cf-54c5f4a05f8so1258366a12.0 for ; Sat, 02 Dec 2023 02:42:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701513751; x=1702118551; 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=+I6MLsJiDM3URhb+RbXbP5Ake1sH71it2g3WR1sCNEg=; b=Qa6FVMfADyn5wMIcilxFePsYdy0LwgUwTNE95t9j6pMEv9KkjhnDjG7cttec2aUtN+ oXlBq6VFN9fP816MDyvXe9ktF/spDC9pjtQcBTscWVZruvexPpv9ALx8E7HIOcvWVVk+ ResbcaFMLvroI7Wdm9zdN3QcE6eAZK+hy5QR9t7mVXX8fU2D6XwQFokK2774jYijKZeh qHoTBng10dmGEOOpLErc0oD3H5z3tPkxmXtpdoa3wVi+kgEoz1lYQicrIYLx4mg0y6+r jubwDatQuSj6/CxbzECMheW1FpPAe05s7Msudui56fHQqyDsXNPMOVob4hESLRCBo3Um ZMaQ== X-Gm-Message-State: AOJu0YxKv4mFLfQ/gWx4sTDR3AOszcF8J1P/NYZaB4639g6eIDiXJ2I8 Ogz905qMM/2pMK/rKQ3Ey37jyJsEBWqQkMICR2KXQ7F7rDo3qcoMAqUBnro4SBbCrBlpTCBtPce pXB2kpksCoMoYQV7XbUck+Hc97vp6E0Onak9zuENaSz3KGwQtiLzyYGe68uwGpNGgCFA1AFbr+F b+2BKc7g== X-Received: by 2002:a50:d5c8:0:b0:54c:4837:8b62 with SMTP id g8-20020a50d5c8000000b0054c48378b62mr1615029edj.48.1701513751246; Sat, 02 Dec 2023 02:42:31 -0800 (PST) X-Google-Smtp-Source: AGHT+IEa89YQwCoAqop1l5j0Gu2aNKO5/k6Uc34CC0nHA4/0AAoZwCdzzn2acagKpcond1zsDJbaQw== X-Received: by 2002:a50:d5c8:0:b0:54c:4837:8b62 with SMTP id g8-20020a50d5c8000000b0054c48378b62mr1615025edj.48.1701513750924; Sat, 02 Dec 2023 02:42:30 -0800 (PST) Received: from localhost (92.40.184.5.threembb.co.uk. [92.40.184.5]) by smtp.gmail.com with ESMTPSA id s10-20020a056402036a00b0054c671a4bd2sm1169584edw.20.2023.12.02.02.42.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 02:42:30 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv6 03/10] gdb: change 'if' to gdb_assert in update_dprintf_command_list Date: Sat, 2 Dec 2023 10:42:11 +0000 Message-Id: <6dd2d5c964b391a3c5eb44b4c5bdac39dd595ac3.1701513409.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=-8.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_ABUSEAT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, RCVD_IN_SBL_CSS, 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 bd28236ce7d..c629d27c4c0 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);