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.129.124]) by sourceware.org (Postfix) with ESMTPS id 992AF3858C60 for ; Tue, 7 Dec 2021 11:08:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 992AF3858C60 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-429-thQBftSZObSPkLwWsPO_2Q-1; Tue, 07 Dec 2021 06:08:36 -0500 X-MC-Unique: thQBftSZObSPkLwWsPO_2Q-1 Received: by mail-wr1-f69.google.com with SMTP id k8-20020a5d5248000000b001763e7c9ce5so2813909wrc.22 for ; Tue, 07 Dec 2021 03:08:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=xxLwXLWhuKI6Npmq7m5q58/LU3L7SgfCV1UVsz7Ofg8=; b=mPLg1H4WJM+DplpgknUf2uqXZigA6EM76h/AE8To93caUgICvHo7+Z2OgVzPtyBGEL dh6soLOR6Qh5T232ENZb3amq+ki3IffgTEVvCL4nTTo9tlMpFXqkbAhsJ16BwYd1w6Va Vv3X5pek8CGJl74HLzVtyzbG47EAl76oE9xyK/j/R3+mC7bKLYmLLW377h0+goMw916A cCdtfqgdgxwpjmwnNjzYzupiwcP8WpUAZtADtcvbKiYpvh9LjKakKHJMe9iTT6KYU18n 9yCibZQOJ3MZVwd1eCOwYorWwRRwgT6l9TRaE7dUB7exINXSKDZEbTyFJcRbbnhl1U+1 mQmg== X-Gm-Message-State: AOAM531jeHtwrkxZrsXEyZf3UT86AoTz/YENcePv5ANyLvdoKKN+KZVX 7y87ZzyliiZFczhzU8+huXt7+FLwFcXwCNVcBtXLFfag6t+9PRRCoYN2cMRrZ5OfZwfh92tRzek b/nxyQA+4vU0= X-Received: by 2002:adf:dc0a:: with SMTP id t10mr50447224wri.8.1638875314865; Tue, 07 Dec 2021 03:08:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJx4b8/qihOD9BjMmW5hHhtANruymtQ3+a1EOZ/5uOnMihjxDzTc9hS5hjEa6LhCNXhF28supw== X-Received: by 2002:adf:dc0a:: with SMTP id t10mr50447199wri.8.1638875314613; Tue, 07 Dec 2021 03:08:34 -0800 (PST) Received: from localhost (host86-134-238-138.range86-134.btcentralplus.com. [86.134.238.138]) by smtp.gmail.com with ESMTPSA id n15sm2271967wmq.38.2021.12.07.03.08.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Dec 2021 03:08:34 -0800 (PST) Date: Tue, 7 Dec 2021 11:08:33 +0000 From: Andrew Burgess To: Simon Sobisch Cc: gdb@sourceware.org Subject: Re: How to recognize `exec-interrupt` via Python events Message-ID: <20211207110833.GF123597@redhat.com> References: <74ce7f64-4368-aee4-1150-28cbd9cc6ae1@gnu.org> MIME-Version: 1.0 In-Reply-To: <74ce7f64-4368-aee4-1150-28cbd9cc6ae1@gnu.org> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 11:02:18 up 1 day, 1:04, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 11:08:41 -0000 * Simon Sobisch via Gdb [2021-12-06 21:11:23 +0100]: > It is possible that I've just overlooked something, but I can't seem to get > an event triggered at all: > > gdb.events.stop.connect(stop_handler) > > is triggered after each step/next, a expected; also on signals including > SIGINT, also when pressing CTRL+C when the inferior is running, type can be > checked with > > if type(event) is gdb.StopEvent > > When the MI frontend (Vim in this case, but this should also apply to Emacs > and others) executes `-exec-step` or `-exec-next` the event is triggered, > when the inferior is running and a breakpoint/watchpint is triggered, too. > But when the inferior is running and `-exec-interrupt` is triggered then the > python code seems to not get an event at all - do I need to connect to a > different event registry? Maybe I'm not understanding your problem description, here's my session trying to reproduce the issue: ##### START ##### $$$ cat test.c #include int main () { while (1) sleep (1); return 0; } $$$ gcc -g3 -O0 -o test.x test.c $$$ cat stop-event.py import gdb def stop_handler(event): print("stop event: %s" % event) gdb.events.stop.connect(stop_handler) $$$ gdb --version GNU gdb (GDB) 11.1 Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. $$$ gdb -q -i mi test.x =thread-group-added,id="i1" =cmd-param-changed,param="print pretty",value="on" ~"Reading symbols from test.x...\n" (gdb) -gdb-set mi-async on ^done (gdb) source stop-event.py &"source stop-event.py\n" ^done (gdb) -exec-run =thread-group-started,id="i1",pid="2623705" =thread-created,id="1",group-id="i1" =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7fd3110",to="0x00007ffff7ff2bb4"}] ^running *running,thread-id="all" (gdb) =library-loaded,id="/lib64/libc.so.6",target-name="/lib64/libc.so.6",host-name="/lib64/libc.so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7df36b0",to="0x00007ffff7f40c5f"}] -exec-interrupt ^done (gdb) ~"\nProgram" ~" received signal SIGINT, Interrupt.\n" ~"0x00007ffff7e9c1e7 in nanosleep () from /lib64/libc.so.6\n" *stopped,reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",frame={addr="0x00007ffff7e9c1e7",func="nanosleep",args=[],from="/lib64/libc.so.6",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="9" ~"stop event: \n" quit &"quit\n" =thread-exited,id="1",group-id="i1" =thread-group-exited,id="i1" $$$ ##### END ##### Notice, the 6th line from the end of the session: ~"stop event: \n" This is the stop event arriving after the -exec-interrupt. This was with gdb 11.1, but I also tested 10.2, 9.2, and 8.3.1, all gave the same results. Could you provide an example .py file, and a precise sequence of MI commands that reproduce the issue you're seeing. Thanks, Andrew