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 461243853D09 for ; Wed, 23 Aug 2023 15:59:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 461243853D09 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692806369; 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=HYHDZgQsxIvgarH1Q3Rp4N3s5K2UTFsA/JyZWZDXcW8=; b=i3RRTEJqOJq6G4Yk9lXIZg8E37XJlazZc974VRt6NrBTQ8JSaOQCXUlNd0ZhT9hpO62SNK e/seglDWvsGMeV2hmUvOGEeepqyHkdYiHpK6w13XXw3pgmQacERLFD6VeSmNg4+tqG8vya am+4gyFECt5BJBIziEHrJAqZAvts03c= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-536-ptJAYNQwOjS_vMN6DwTJtA-1; Wed, 23 Aug 2023 11:59:28 -0400 X-MC-Unique: ptJAYNQwOjS_vMN6DwTJtA-1 Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-2bcba79cedcso38713671fa.1 for ; Wed, 23 Aug 2023 08:59:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692806367; x=1693411167; 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=HYHDZgQsxIvgarH1Q3Rp4N3s5K2UTFsA/JyZWZDXcW8=; b=iwslldWMeghR4b0JihdGWUbd223dxeI4k0BDMm8EtGAXfcqn/oRcSGLdSADrdZCPLA gsOjgX1nBBqum8EgKHY9rGcVuCvUBn7BDpNbTjkIblwjRZIkICw5gq2XHtAvEwf5ygwi WeJ3ejmYiYP+u4BJ536TqHiBwmWh+m4Ah1QOMQJNBrc7RKlez6LYOF8QO/bEKLNKJA2O /3CDB+hj/Gfdq82Sll4vRxCPzEoxWjNojcYlLIKSAQgaN2S7l2dpu+VZLP+KaM3PfGsK HBsUHAxTNd//faazHbLPRX2AbYXy40ynUJA0sDFaI9DYcmZ2nR1iM85l41rOpSreA9bH ZZhQ== X-Gm-Message-State: AOJu0Yw549f8mBr2+QO2qz3tK+b75Vnk4MV+iv1xTQ47u4B8CZL400bP 0ou4XaBvdWQUYOMXjY5O/0YT3UiF/bK0lqHyer9vr37smezg89X/8T3rn73/dllC6bc4bVOnu5D r75jFnZcOexnCzNWbj3nMW+dm40A56UT6ZuEOueT9AnTkkH+izcnofjwAlTj3colqs7l9CC50xE LcpAp27Q== X-Received: by 2002:a2e:9b97:0:b0:2bc:b694:6d6e with SMTP id z23-20020a2e9b97000000b002bcb6946d6emr8333530lji.27.1692806367024; Wed, 23 Aug 2023 08:59:27 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHlNA8aFKwMS7onD1Dmvo/W+Z+dBjW9dglS79LOealDviNQZpEbslhAZJmnC1PlWmdieTobZQ== X-Received: by 2002:a2e:9b97:0:b0:2bc:b694:6d6e with SMTP id z23-20020a2e9b97000000b002bcb6946d6emr8333509lji.27.1692806366592; Wed, 23 Aug 2023 08:59:26 -0700 (PDT) Received: from localhost ([31.111.84.232]) by smtp.gmail.com with ESMTPSA id s1-20020a1709067b8100b00993150e5325sm9993501ejo.60.2023.08.23.08.59.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Aug 2023 08:59:25 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv4 03/10] gdb: change 'if' to gdb_assert in update_dprintf_command_list Date: Wed, 23 Aug 2023 16:59:08 +0100 Message-Id: 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 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-11.8 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: 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 66d52fd2f07..86225ef82fa 100644 --- a/gdb/breakpoint.c +++ b/gdb/breakpoint.c @@ -8543,8 +8543,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); -- 2.25.4