From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) by sourceware.org (Postfix) with ESMTPS id 3FCE83857437 for ; Fri, 17 Feb 2023 17:49:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3FCE83857437 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f53.google.com with SMTP id m21-20020a05600c3b1500b003e1f5f2a29cso1546977wms.4 for ; Fri, 17 Feb 2023 09:49:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cZV0ijRo4jcECtoun1ux+VWa6pLfg3X+XwMTU+WnY0E=; b=hE4QyhgbPh7TERcDHmrbp7v8+ZyA3tiWUI4tPEmS91Gz2AoCNK2oiF1sAuAHbk5BsN kH6SofjTyC9tGMURrgMJU+CxEc8n+rOv4ACYe3zFZKY77PrNqbZEAh9Bp52Krp1glRG6 c/26441foxb5FO9DVQ+FEKdbKJMi1aizPt11xJTGEka1rO/mweJ9gfHnVPhFodPiO0nD +lyulx+rdXJq8VMLvEXzSLZBo92cl03H4A1s5bELT+Rw4fNh4w0o41SzsZdLIH6dL1Pc 43jOTMqBpZ3V8NmrepIic0qmzmeQvQsiGX8txVyUrQg+KGMM520JH/17InY8QtFILxLZ FhKQ== X-Gm-Message-State: AO0yUKUaPKUowH929ojTKH8gNw6fKNaPHudnZ3ZEo3iucIaNDfL1Kz/H PX65faqwLI0e1iZiIcKXscNoqDiCtD7tsQ== X-Google-Smtp-Source: AK7set/B88WC89/ivDHJSxo2X+Q0R5ZjjcQzMtNnKOksaprkzXOt4IMDJaIvHWc6AoOVIw7kJB+LKg== X-Received: by 2002:a05:600c:2e87:b0:3e2:201a:5bcc with SMTP id p7-20020a05600c2e8700b003e2201a5bccmr2268244wmn.33.1676656164772; Fri, 17 Feb 2023 09:49:24 -0800 (PST) Received: from ?IPv6:2001:8a0:f92b:9e00::1fe? ([2001:8a0:f92b:9e00::1fe]) by smtp.gmail.com with ESMTPSA id s9-20020adff809000000b002c6eb1fc07asm453120wrp.31.2023.02.17.09.49.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Feb 2023 09:49:24 -0800 (PST) Subject: Re: [PATCH 3/3] gdb: don't use the global thread-id in the saved breakpoints file To: Andrew Burgess , gdb-patches@sourceware.org References: <22df7afc-cf88-d260-516d-7b9a45e2ad78@palves.net> <87pmahuxzu.fsf@redhat.com> From: Pedro Alves Message-ID: <00607ab6-b94c-869c-5d1a-7528cf4dd85f@palves.net> Date: Fri, 17 Feb 2023 17:49:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <87pmahuxzu.fsf@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP 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: Hi! On 2023-02-10 7:22 p.m., Andrew Burgess wrote: > Pedro Alves writes: > >> On 2023-02-08 3:23 p.m., Andrew Burgess via Gdb-patches wrote: >> >>> breakpoint::print_recreate_thread (struct ui_file *fp) const >>> { >>> if (thread != -1) >>> - gdb_printf (fp, " thread %d", thread); >>> + { >>> + struct thread_info *thr = find_thread_global_id (thread); >>> + gdb_printf (fp, " thread %s", print_thread_id (thr)); >> >> print_thread_id only prints the inferior-qualified thread id if >> there are multiple inferiors. I am wondering whether the save breakpoints >> file should _always_ end up with inferior-qualified thread ids, so that >> reloading the saved file works the same if you meanwhile add another >> inferior. > > As a counter argument; if the user has a single inferior and places > breakpoints on a particular thread, we'll have a save like: > > break foo thread 2 > > Then if the user sets up two inferiors, they can select which inferior > the breakpoints should apply to - source the saves from inferior 2, and > the b/p will apply to inferior 2 threads, source from inferior 1, and > the b/p will apply to inferior 1 threads. > > If the user has changed the inferior setup when sourcing the breakpoint > save file, I think they have to take some responsibility for knowing > what they want ... maybe? > > If you feel strongly then it's easy enough to print the qualified > thread-id, just let me know and I'll get it done. > 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. Pedro Alves > Thanks, > Andrew > >> >> Otherwise, >> >> Approved-By: Pedro Alves >