From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 4ICSFoS+aGPE4hQAWB0awg (envelope-from ) for ; Mon, 07 Nov 2022 03:15:00 -0500 Received: by simark.ca (Postfix, from userid 112) id 58F381E124; Mon, 7 Nov 2022 03:15:00 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=kThMaMKe; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C88CC1E0CB for ; Mon, 7 Nov 2022 03:14:59 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A25F13858418 for ; Mon, 7 Nov 2022 08:14:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A25F13858418 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667808896; bh=mZcBfB8quJ1+ufx5y7h7qzE9XpKYTUu8TqBKjmcdCiY=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=kThMaMKepxmXDK2Cpw9n5MfHjGhLelYJj2K7GyHYSs61113zot2Ts6CJDr/V7EQwG QaYCODzRrnOgZRacnz3B2z2yKU96QjSQ3wg60D107zUoBkj8hNu7pv6+jGEKadDiq8 Mvlt4GWcZZx3bPiMY6/mVmFXsDJdw4TUg5Nlb7DE= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 540D03858C1F for ; Mon, 7 Nov 2022 08:14:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 540D03858C1F 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_128_GCM_SHA256) id us-mta-653-WKai5V8rOKWen8lM7p-wEA-1; Mon, 07 Nov 2022 03:14:29 -0500 X-MC-Unique: WKai5V8rOKWen8lM7p-wEA-1 Received: by mail-ed1-f72.google.com with SMTP id s15-20020a056402520f00b0046321fff42dso7714488edd.0 for ; Mon, 07 Nov 2022 00:14:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mZcBfB8quJ1+ufx5y7h7qzE9XpKYTUu8TqBKjmcdCiY=; b=1I/4u21eK7kFSAN40axSJ7e2HjWuBut3VRdP8XAuzKC2OFoJmZGhUV3NXB/1wWXOgq XXgZXLieMgioBdDVAHJVYVwjjK/bIeGCnd/wRHyFMAio6DLD2+v93uVH6t3ELNVOhaZv jO4lHzFMYEOrvBU/aiSrz00uIt0VNMyiZGH52ZCbYfEKHz0zQCMvEXbGcFFwnGYGGsnH YLXerpyRs19gfSy7isQYVBkzPFvGter6GDFWbe7nORWqNJZi3BCacQSPWssIMigk3QDj m9m2H+AM6bRtsVWbOQ5c8ZXIOxdOz/FZ9xyABT2YMDQgtgY4TgibFHHAh9ea0MuZWRX/ +dag== X-Gm-Message-State: ACrzQf2x4QYsunqf904XHG+5JbMXHiGMv0Sv7nfOiUMvcBf5BM/jCwLc JT11HjOs5sKr9CK86Ff//8Ty3Relo9ZPQSCFHZgALYMxTJF/Q7chPDRBusXbLq87HYkeOn6Vezi g3TUbGA7LyoV+mmEZjb9adg== X-Received: by 2002:a17:906:fd84:b0:730:acee:d067 with SMTP id xa4-20020a170906fd8400b00730aceed067mr47060234ejb.206.1667808868029; Mon, 07 Nov 2022 00:14:28 -0800 (PST) X-Google-Smtp-Source: AMsMyM4KHGdIN5IdUZX12q9WDObCNxJs5v5JmP5wbg1wPW+d64Knhc3+Kpnd2C/kODHQxW/dV0bx0g== X-Received: by 2002:a17:906:fd84:b0:730:acee:d067 with SMTP id xa4-20020a170906fd8400b00730aceed067mr47060216ejb.206.1667808867700; Mon, 07 Nov 2022 00:14:27 -0800 (PST) Received: from [192.168.0.45] (ip-62-245-66-121.bb.vodafone.cz. [62.245.66.121]) by smtp.gmail.com with ESMTPSA id kv15-20020a17090778cf00b007adf125cde4sm3090534ejc.13.2022.11.07.00.14.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Nov 2022 00:14:27 -0800 (PST) Message-ID: <2cd08b65-12e0-3763-5f41-cc1caad4f554@redhat.com> Date: Mon, 7 Nov 2022 09:14:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: [PATCH] gdb: make "start" breakpoint inferior-specific To: Simon Marchi , gdb-patches@sourceware.org References: <20220804174035.2441960-1-simon.marchi@efficios.com> In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Bruno Larsen via Gdb-patches Reply-To: Bruno Larsen Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 04/11/2022 17:52, Simon Marchi wrote: > On 8/31/22 10:03, Bruno Larsen via Gdb-patches wrote: >> On 04/08/2022 19:40, Simon Marchi via Gdb-patches wrote: >>> I saw this failure on a CI: >>> >>>      (gdb) add-inferior >>>      [New inferior 2] >>>      Added inferior 2 >>>      (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: add-inferior >>>      inferior 2 >>>      [Switching to inferior 2 [] ()] >>>      (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: inferior 2 >>>      kill >>>      The program is not being run. >>>      (gdb) file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep >>>      Reading symbols from /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep... >>>      (gdb) run & >>>      Starting program: /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep >>>      (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: run inferior 2 >>>      inferior 1 >>>      [Switching to inferior 1 [] ()] >>>      (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: inferior 1 >>>      kill >>>      The program is not being run. >>>      (gdb) file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior >>>      Reading symbols from /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior... >>>      (gdb) break should_break_here >>>      Breakpoint 1 at 0x11b1: file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.threads/vfork-multi-inferior.c, line 25. >>>      (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: break should_break_here >>>      [Thread debugging using libthread_db enabled] >>>      Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". >>>      start >>>      Temporary breakpoint 2 at 0x11c0: -qualified main. (2 locations) >>>      Starting program: /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior >>>      [Thread debugging using libthread_db enabled] >>>      Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". >>> >>>      Thread 2.1 "vfork-multi-inf" hit Temporary breakpoint 2, main () at /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.threads/vfork-multi-inferior-sleep.c:23 >>>      23      sleep (30); >>>      (gdb) FAIL: gdb.threads/vfork-multi-inferior.exp: method=non-stop: start inferior 1 >>> >>> What happens is: >>> >>>   1. We start inferior 2 with "run&", it runs very slowly, takes time to >>>      get to main >>>   2. We switch to inferior 1, and run "start" >>>   3. The temporary breakpoint inserted by "start" applies to all inferiors >>>   4. Inferior 2 hits that breakpoint and GDB reports that hit >>> >>> To avoid this, breakpoints inserted by "start" should be >>> inferior-specific.  However, we don't have a nice way to make >>> inferior-specific breakpoints yet.  It's possible to make >>> pspace-specific breakpoints (for example how the internal_breakpoint >>> constructor does) by creating a symtab_and_line manually.  However, >>> inferiors can share program spaces (usually on particular embedded >>> targets), so we could have a situation where two inferiors run the same >>> code in the same program space.  In that case, it would just not be >>> possible to insert a breakpoint in one inferior but not the other. >>> >>> A simple solution that should work all the time is to add a condition to >>> the breakpoint inserted by "start", to check the inferior reporting the >>> hit is the expected one.  This is what this patch implements. >>> >>> Add a test that does: >>> >>>   - start a background inferior 1 that calls main in a loop >>>   - start aninferior 2 with the "start" command >>>   - validate that we hit the breakpoint in inferior 2 >>> >>> Without the fix, we hit the breakpoint in inferior 1 pretty much all the >>> time. >>> >>> Change-Id: Ib0148498a476bfa634ed62353c95f163623c686a >> Hi Simon, >> >> This change makes a lot of sense, I just wonder if it would make sense to make breakpoints inferior-specific. I could see a situation where someone would run the same program twice, one with an ok input while the other has a buggy input for instance, to see the difference between them, and inferior-specific breakpoints could come in handy in a situation like this. >> >> If you think it would be too much work for a usecase that is too niche, this patch is pretty straight forward, I'd suggest you approve your patch. > I certainly don't want to add a new user-facing feature just for this > fix, as that's a lot of work (figuring out the syntax, doc, NEWS, tests, > etc). We could enhance the internal API to allow passing an inferior to > make a breakpoint inferior-specific, but I don't think it should be a > prerequisite for this fix. It would end up doing functionally > identical. What I had in mind is closer to your second idea, just internal API changes to keep track of the inferior, though maybe I just hadn't thought through the suggestion, since letting users add breakpoint to other inferiors makes sense given the use case I mentioned above. This is a long winded way of saying I agree that this is unreasonable feature creep for a functionally identical end result for now, so the patch LGTM. Reviewed-By: Bruno Larsen Cheers, Bruno > > Would you like to to add your Reviewed-By on this patch? > > Simon >