From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta034.useast.a.cloudfilter.net (omta034.useast.a.cloudfilter.net [44.202.169.33]) by sourceware.org (Postfix) with ESMTPS id E452B384CBAF for ; Fri, 15 Dec 2023 20:53:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E452B384CBAF Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E452B384CBAF Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=44.202.169.33 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702673603; cv=none; b=hUYNUkkb/VS0yHM94VF0TJKGHSEWirkccHXWjtMK2m1w7s6S8yGdGBz4THR4sw1qcABo0uKpafLkR160sgKeM4WPjtz3LyG7axpghOK+eFQtDEgewjSi2/uYUOtV1LC9oC6BMddP/y6hO3dVq9xUUTqiY1VcxFwsB6G5KWKg2UQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702673603; c=relaxed/simple; bh=+ASoEIwVEVGuLPTsNWczhL4JnRY9O97IiMVra9HJbPA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=f/V1Ksdz1RAesn/zrGbcxKWx+y7odH73qo9Srb7drYTsrD6MZ8Nw3WUAUsdJ6nu66XObqvADrgs+DVLNcWuOfHMgJN9uLGXZGN7U3N0gZpz/n/paz+UTy2JvnhZAbf7LvJVe0w1OgKse8SAWc1cA+Uhs0//TeAErb7PAjIhONpI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from eig-obgw-5003a.ext.cloudfilter.net ([10.0.29.159]) by cmsmtp with ESMTPS id EAjTrXHryjtZ3EFBZrDOdN; Fri, 15 Dec 2023 20:53:29 +0000 Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTPS id EFBOrwvTpnCfvEFBOr4WEL; Fri, 15 Dec 2023 20:53:19 +0000 X-Authority-Analysis: v=2.4 cv=KKpJsXJo c=1 sm=1 tr=0 ts=657cbcbf a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=OWjo9vPv0XrRhIrVQ50Ab3nP57M=:19 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=e2cXIFwxEfEA:10 a=Qbun_eYptAEA:10 a=20KFwNOVAAAA:8 a=KgIGfF43Uyc-3feugOwA:9 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=C+iaTKY20j7xPSQ+XAW7zHVps2JFfcCXGewU+i46VX8=; b=o+Myhx7TmbHk3AunF7Pnyopf5p coYJzLLyVE6oTE8B1yY/tO5Dd2Wfo8qM6ZgeLo93Cvh9Rb7aFVgsBC/hQKiw3aDOaMHaDzv29PjTF jxObWR2WejhWrqHeGT/0aWEdk; Received: from 71-211-161-25.hlrn.qwest.net ([71.211.161.25]:45166 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from ) id 1rEFBO-004ElI-0Y; Fri, 15 Dec 2023 13:53:18 -0700 From: Tom Tromey To: Andrew Burgess Cc: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: [PATCHv7 07/11] gdb: parse pending breakpoint thread/task immediately References: <16e9732a00d369533933ea939753a940d8c5a560.1702507015.git.aburgess@redhat.com> X-Attribution: Tom Date: Fri, 15 Dec 2023 13:53:17 -0700 In-Reply-To: <16e9732a00d369533933ea939753a940d8c5a560.1702507015.git.aburgess@redhat.com> (Andrew Burgess's message of "Wed, 13 Dec 2023 22:38:31 +0000") Message-ID: <878r5v5gsi.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 71.211.161.25 X-Source-L: No X-Exim-ID: 1rEFBO-004ElI-0Y X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 71-211-161-25.hlrn.qwest.net (murgatroyd) [71.211.161.25]:45166 X-Source-Auth: tom+tromey.com X-Email-Count: 4 X-Org: HG=bhshared;ORG=bluehost; X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-CMAE-Envelope: MS4xfBc6SNXGCWa1kxneWLKtgNLEKJEEhlXQAtjQfk5/VKzCuH1GXWZa5VQzkWjyhIYv5VLXM4MZrYNPPxMiHwV9CSQgCImxrvOZpNoGVfyD02ADz1w0cXDj Ltw/0BMl7ZEj71CGo1cnyVbdG54IgNvj8wJ6a56SX2jaFhPP4Qc7wLPQ3mS3cL2oXcASp0OuwE8qm0qB6v3DCBO17MV5INBJTcg= X-Spam-Status: No, score=-3016.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: >>>>> "Andrew" == Andrew Burgess writes: Andrew> As a result of this commit the breakpoints 'extra_string' field is now Andrew> only used by bp_dprintf type breakpoints to hold the printf format and Andrew> arguments. This string should always be empty for other breakpoint Andrew> types. This allows me to clean up some code in Andrew> print_breakpoint_location. I wonder if this member can be pushed into struct dprintf_breakpoint. (I don't think you should do that in this series, you've been waiting long enough.) Andrew> 2. The handling of '-force-condition' is odd, if this flag appears Andrew> immediately after a condition then it will be treated as part of the Andrew> condition, e.g.: We probably should have required this to appear before the linespec. Maybe also thread/task/etc. Andrew> +/* Return true if STR starts with PREFIX, otherwise return false. */ Andrew> + Andrew> +static bool Andrew> +startswith (const char *str, const token &prefix) Andrew> +{ Andrew> + return strncmp (str, prefix.data (), prefix.length ()) == 0; Andrew> +} I wouldn't mind this in common-utils.h alongside the other startswith, but it's fine here too. Andrew> + test (" if blah ", "blah"); Andrew> + test (" if blah thread 1", "blah", global_thread_num); Andrew> + test (" if blah inferior 1", "blah", -1, 1); Andrew> + test (" if blah thread 1 ", "blah", global_thread_num); It seems like there are some confounding cases, where gdb would previous (rightly) give a syntax error, but where now they may be passed through without notice. I thought of some... maybe in the "don't care" bucket. I mean, it would be nice if we could do a little better, since I guess the user could typo and then wind up with a breakpoint that's never really useful, like: break some_future_function -force-condition if x == thread 5 Will this ever yield an error? Maybe the user accidentally left out the right-hand-side of that 'thread'. Or maybe meant to write "thread thread". Probably the worst cases involve deliberately confounding macro definitions, but these IMO are definitely "don't care". Maybe advising the user to surround the 'if' in parens and that's enough, assuming: break func if ( x == thread ) ... does the right thing. Tom