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 37CFD3858C74 for ; Mon, 20 Mar 2023 10:38:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 37CFD3858C74 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=1679308727; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=83MkNrMZdEwZKAKn/D9/xqxRUEIpKhygZMAZXyOXVEE=; b=LhNFVYGFq/OuLCLaY05OvByFYOmwoq36V1QZTMdVUW1ILpn6d5u8JIF2ERCd+MELw2ffnV Ndr7+DL+2QKHoyRA908B2NUZIgYkbnCzKs7I3IrOGWS8Jl6lyLcD+aaybbCcUjnBpihKDn DDzjswWkhq0sf+DAXYe1UsqiXovL6E0= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-658-hM8OwQvZPFS9Q7HMVDFqWA-1; Mon, 20 Mar 2023 06:38:44 -0400 X-MC-Unique: hM8OwQvZPFS9Q7HMVDFqWA-1 Received: by mail-ed1-f70.google.com with SMTP id p36-20020a056402502400b004bb926a3d54so16676545eda.2 for ; Mon, 20 Mar 2023 03:38:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679308723; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=83MkNrMZdEwZKAKn/D9/xqxRUEIpKhygZMAZXyOXVEE=; b=EQymGdfacmMuAOJmM54/XtmHyrYRWKWg684ts/rD3Jb4mnZ20Gtwg7tPa6M/MAa10l SybygL/nUdw6LEquH3AB1rfR23puHtsIaCYRBFzzupUaMpOdeL8QFr5Y4kQsznNBe0ca OEeb3MzEcDRjNwTVV8omyhTB4CA6EYk7gW5MCIJqWXQVbtfVvLtIBXk5HeQmNiAa+kXA 4ciO/FsIxb1wPvPUwSV0LtMu/OCYZZFntfk3qs7tZCnvrYc/RE3x/gZrNVAdx1W88+0C KM9xYGiWSNX74V4smWafhMJD6rFxOTcJFLavOGNQjkjwgsJlF7F13pcZdqcbqhFbXT1V m7Ug== X-Gm-Message-State: AO0yUKUctc/LKGHHyfYdcGf7VLHRAf8s9uIM/u9jtCq03LsYjTlZ09iR lgKSIoOpci5Uv+lfZ2RMw0sQ4RkacRzHDNKgxNH+dAtjX1hj5Zk1G3YbA35gSXrEpddO36jA6FW IIpTrm8/TRewmBH6BbKUdCNyAKPmt4A== X-Received: by 2002:a17:906:fa02:b0:932:40f4:5c49 with SMTP id lo2-20020a170906fa0200b0093240f45c49mr8468029ejb.67.1679308723016; Mon, 20 Mar 2023 03:38:43 -0700 (PDT) X-Google-Smtp-Source: AK7set+fUKmDv7NRhevbzZMribCGfQbje+cdadoGnvOQapObf5Z0/nlg7xpQCXgR930DJmrrM0yrXA== X-Received: by 2002:a17:906:fa02:b0:932:40f4:5c49 with SMTP id lo2-20020a170906fa0200b0093240f45c49mr8468023ejb.67.1679308722778; Mon, 20 Mar 2023 03:38:42 -0700 (PDT) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id fi9-20020a170906da0900b00931faf03db0sm3967449ejb.27.2023.03.20.03.38.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Mar 2023 03:38:42 -0700 (PDT) From: Andrew Burgess To: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [PATCH 3/3] gdb: don't use the global thread-id in the saved breakpoints file In-Reply-To: <1e720fd6-58d5-a478-847c-8e56f46d0e8e@palves.net> References: <22df7afc-cf88-d260-516d-7b9a45e2ad78@palves.net> <87pmahuxzu.fsf@redhat.com> <00607ab6-b94c-869c-5d1a-7528cf4dd85f@palves.net> <87o7pej3ir.fsf@redhat.com> <87ttykeid0.fsf@redhat.com> <1e720fd6-58d5-a478-847c-8e56f46d0e8e@palves.net> Date: Mon, 20 Mar 2023 10:38:41 +0000 Message-ID: <87fs9zemha.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.7 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_H2,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: Pedro Alves writes: > On 2023-03-16 5:06 p.m., Andrew Burgess wrote: >> Andrew Burgess writes: >> >>> Pedro Alves writes: >>>> >>>> On 2023-02-10 7:22 p.m., Andrew Burgess wrote: >>>>> Pedro Alves writes: > >>>> My thinking is that internally, the thread is really inferior-qualified. >>>> It is just a presentation detail in the CLI that we don't print the >>>> inferior when there's only one inferior, for backwards compatibility. >>>> That may even change in the future. An MI frontend / GUI may be presenting >>>> the qualified ID, for instance. >>>> >>>> It seems to be that there are two valid approaches: >>>> >>>> #1 - we consider what the user typed when the breakpoint was created as canonical, >>>> and thus we save the breakpoint using the same breakpoint spec string that >>>> user typed originally, meaning, if the user typed: >>>> >>>> "break foo thread 1" >>>> >>>> then that's what we'd save, even if the user added a second >>>> inferior after creating the breakpoint. >>>> >>>> Of course, it follows then that if the breakpoint is created with >>>> >>>> "break foo thread 1.1" >>>> >>>> then that's what we save. So the user would have the option. >>>> >>>> I'm really not sure whether this is an option that we should be giving >>>> users, though. What if the breakpoint was created via Python, or via the >>>> MI with --thread ? Then the concept of original "thread" may not even exists, >>>> even though we save such a breakpoint too. >>>> >>>> #2 - we consider that the thread that the breakpoint ended up bound to is what >>>> is canonical and thus we always print the qualified id to the file. >>>> >>>> The approach in your patch is neither of the above -- it prints the qualified >>>> or non-qualified thread id depending on a CLI presentation detail, which seems >>>> brittle to me. >>>> >>>> Option #2 seems the simplest to explain, document, and implement, to me, >>>> but I could be convinced to go with #1 too. >>> >>> Thanks for the explanation. I've implemented #2 in the patch below, >>> what are your thoughts? > > Sorry for the delay. (I simply forgot to reply.) It looks good to me. > Not a problem. Now pushed. Thanks, Andrew