From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Skip Montanaro Newsgroups: gmane.emacs.help Subject: Re: Executing Emacs commands when a gdb breakpoint is hit Date: Wed, 22 Jan 2020 15:07:57 -0600 Message-ID: References: <83o8uwvekv.fsf@gnu.org> <831rrrv2vq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="39044"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Help GNU Emacs To: Eli Zaretskii Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 22 22:08:51 2020 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iuNF4-000A7m-VI for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 22 Jan 2020 22:08:50 +0100 Original-Received: from localhost ([::1]:46930 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuNF4-00082B-2A for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 22 Jan 2020 16:08:50 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58562) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuNEk-000823-Hv for help-gnu-emacs@gnu.org; Wed, 22 Jan 2020 16:08:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iuNEj-0001FX-BC for help-gnu-emacs@gnu.org; Wed, 22 Jan 2020 16:08:30 -0500 Original-Received: from mail-pg1-x536.google.com ([2607:f8b0:4864:20::536]:34398) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iuNEh-0001EB-1S; Wed, 22 Jan 2020 16:08:27 -0500 Original-Received: by mail-pg1-x536.google.com with SMTP id r11so187786pgf.1; Wed, 22 Jan 2020 13:08:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7WJ++tg+i04oXp18mu+be+prTo6U1nFyuXB7kbSIDq0=; b=gs6iMxtlz8Ih//fFkVFOpopwX65pUe9wDaYvVLIqJ9/YvILNTAmMSIHG3oR1t83Wio lGIH2plO7rxunRuSCRHJJEhMy3yn8TRBaSwhfYMYzNmqpeCN0wMD5HlGaPBid3jfPoPo iJ3052I64tof3fVQpNcIs/DWOhHpmJIkiSnGA87/jgZeYCZbTMFU9yjUWffoQp6D0sxS hCZ6zTkefwo47YpQbX+PB69vNZyOtTbVhX+uXBkrRZe7TtaV3Hf4VLyefx3mbcRLv++V B9vB54FsyjYvitDtHWsGvoVFDMHz9+wg+Ty2SuHbU6DMEtmQADsU4syeQg3eHDDfrvYi sZEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7WJ++tg+i04oXp18mu+be+prTo6U1nFyuXB7kbSIDq0=; b=TmmfHCRD0Uyo3eDQk+b2QVukzKXdr35D9Z/OPWnJKmscB3UVWFQ2GBgIW2QnuVlZR7 s9Im3x56CDpdjL2n6dru0OF5qxGjH2yygSswVcUcl1XIfKadpczEG5NyNidBPAetl7H6 y6TZ3L+ULnuLvXYKZ6kVYmUNSx9bzv74HehB3PbFoEAm/c/1yCcp9yFlyyGJ/iABTnwd 8yhjBb/6svq3JPkTCpUGj9xby2pMhBm2FTTc6KIOMdD6Leb0k/ewBDB0CUUg//x+7N3s TJgsPPIjJTcKpq8VxCA0jPq69qj9LQgRiHR/w/RnXk8qw9fWe21YE6Ceyqf4U71qLiw0 f1Sw== X-Gm-Message-State: APjAAAXaayN5J7GMhggiszjmj4kXdzoJemjDA4GDrTTrMJo5EpQwPcnN 9zCvDToLaCDv3eQnERTipqdxmI/1n+ditb7UsqsS4SeNDhVNFZE= X-Google-Smtp-Source: APXvYqxQZW0FuGJsvhOoL0bv3ao+Z/qyIvrG39qQ2HgB4kkhkFzDw3vO1lCiv71LvVgU8wkCcv8U9uGcUwoAa94pBW4= X-Received: by 2002:aa7:9562:: with SMTP id x2mr4358651pfq.147.1579727303651; Wed, 22 Jan 2020 13:08:23 -0800 (PST) In-Reply-To: <831rrrv2vq.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::536 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:122261 Archived-At: > I don't think I understand what you are trying to do and what are the > difficulties, sorry. My apologies. As is so often true with things we work on, it's easy to forget that others aren't as steeped in our problems. It's easy to assume more of one's audience. Here's some more detail. I'm working on the Python bytecode compiler. It's written in C. As I work my way through the process, I want to know where the compiler is currently working. The compiler maintains a number of C structs throughout the process. At the top level is the compiler struct. Here I've only displayed the two fields of interest to me. The c_filename field names the file being compiled. The compiler_unit * field refers to a subsidiary struct which contains (among other bits) the current line and column offset of the current statement being compiled. struct compiler { PyObject *c_filename; ... struct compiler_unit *u; /* compiler state for current block */ ... }; struct compiler_unit { ... int u_lineno; /* the lineno for the current stmt */ int u_col_offset; /* the offset of the current stmt */ ... }; So, I run Python under control of gdb and set a breakpoint in a specific function, compiler_set_lineno. When this breakpoint is reached, I want to query gdb for the current values of c->c_filename and c->u->u_lineno. The first argument to that function is struct compiler *c. Eventually, I will likely be interested in more fields of either of these structs, but for the purposes of interacting with gdb, this is sufficient. I wrote an ELisp function which is an element of the gdb-stopped-functions list. It gets called at the appropriate place when the breakpoint is encountered. I get a useful reason argument for the stoppage and, in particular, can tell whether or not the stoppage occurred in compiler_set_lineno. When this is the case (I might have breakpoints set elsewhere, so would want to bail out if that was the case), I want to evaluate the current Python filename, line number and column. That allows me to update display of the Python file within Emacs and so get a bit of visual context for where the compiler is working. (It works from an abstract syntax tree which is pretty low level. Viewing the compilation context in the source file is quite useful.) The problem I encounter is that the underlying gdb process doesn't seem to be ready to receive input when my stop function is executed. It appears to have been stopped, but the (gdb) prompt isn't visible in the *gud-python* buffer. I want to print the desired expression with (comint-send-input), then read the result. Perhaps I should just set a gdb-level command to print the desired expressions instead. My ELisp code would only then need to read the values from *gud-python*. The advantage of doing everything from within my ELisp stop function is that everything relevant to this display lives in one place. I don't have to synchronize my ELisp with user-level gdb commands. Perhaps there is a comint function which will update the *gud-python* buffer so the (gdb) prompt is visible and the underlying gdb process is truly ready for (comint-send-input)? Skip