From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.devel Subject: Re: Extend gdb to filter registers Date: Sun, 19 Jan 2020 20:22:38 -0500 Message-ID: <8A5A507A-6036-4894-A8B1-749109EBE605@gmail.com> References: <878spmuerf.fsf@mail.linkov.net> <83wod3bx8i.fsf@gnu.org> <9f5ddaa5-0234-a17b-bdd7-81d70a0a50d6@gmx.at> <83FFF194-64CD-409E-8B7A-5A9DF91E79DE@gmail.com> <83v9pb314t.fsf@gnu.org> <838sm510d6.fsf@gnu.org> <83muakzoy5.fsf@gnu.org> <71042c9f-478b-47c8-f27e-1348e9f4536d@gmx.at> <83iml8zkbm.fsf@gnu.org> <6ad85759-7408-f177-38f6-45a72c2f5a9e@gmx.at> <83eevwzi79.fsf@gnu.org> <68ef651e-9319-b392-af1c-4564d5db9112@gmx.at> <831rrvzc81.fsf@gnu.org> <997C9AD2-D8DD-45DC-9195-28FEC907B2C4@gmail.com> <83muajxs04.fsf@gnu.org> <416593FF-C4BE-478F-B5AC-3379235146ED@gmail.com> <83lfq3xp66.fsf@gnu.org> <679953AF-F50A-4ABE-B836-150BA0F95DAE@gmail.com> <83h80rxlae.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_7CD5F7EF-945D-497E-B87A-37BEDB959EA8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="85814"; mail-complaints-to="usenet@ciao.gmane.io" Cc: martin rudalics , emacs-devel@gnu.org, monnier@iro.umontreal.ca, john@yates-sheets.org, juri@linkov.net To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 20 02:23:40 2020 Return-path: Envelope-to: ged-emacs-devel@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 1itLn1-000MHk-RY for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Jan 2020 02:23:39 +0100 Original-Received: from localhost ([::1]:56870 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1itLn0-00018x-TC for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Jan 2020 20:23:38 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41696) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1itLm9-0000ZE-4e for emacs-devel@gnu.org; Sun, 19 Jan 2020 20:22:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1itLm7-0008MS-PI for emacs-devel@gnu.org; Sun, 19 Jan 2020 20:22:45 -0500 Original-Received: from mail-qv1-xf42.google.com ([2607:f8b0:4864:20::f42]:36234) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1itLm5-0008LH-SL; Sun, 19 Jan 2020 20:22:42 -0500 Original-Received: by mail-qv1-xf42.google.com with SMTP id m14so13318936qvl.3; Sun, 19 Jan 2020 17:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qxLE34uletHXrlQIYDvpnReT/g/3/U2Pjmar5mupd4o=; b=IUVjRd/yxPfxLyZuT6cwcnGp15SQ9aFdiJ5qSnCB43KBAJAE2+dDuj5znNMGSZmujy mPEbF+w5PQm5DCMFJgqAmD6F8yg/nbfzNy6Lz1831a1qqGCV4V0n3jv4x0DLYBncEAvw aHDDuZrLG6nxnhJ7tWSF3EDA//NL58SFdbK0ujqCUwsRC4cT3cS84kS46CHxGW0gU1r/ Yl/63GCy3ja9EbnFgfqE1nVKXnY/7IRiiLYBVQTZkyO8JzRQZsjhqtEt0JjjmvbUguil pnq3zrB0er9brbwnC/n/BE2ycNyWK34N+xU0dMg/aFULa/n/x1LDHSIPLxLq4ceKqoDF w7Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qxLE34uletHXrlQIYDvpnReT/g/3/U2Pjmar5mupd4o=; b=biTUtwpuzH1/RLEb+nV1kBarvO4rpSa0FuwYcfG+agwFjyh+LNp7Tp+kZ0gUauf1vS 8sTc8cOEmwLnl2LHeox2HiQrlglxgVSorvxkL8RVisgJgKWIcGgE2faio6bj7r+DBDUt Dxogr6PSraCwXHCqRZ+gC84Pf0MxdX92R7jy0Sp7v2NT/e7rfZsaTMe4FIf0bHeNNfrs dB9na0PmGo1gOfvaVdQjj3RiPzMsrr6YrMOd9QL1lYfpQAaKwPil6xYdCvTdd1h+hmv/ RCOpSqhic2Q2F1zdnwO5w+XJQJqRogD8adNICE03wRcU8YekdXfgiwmgNKFqq7nhb3X4 wyqg== X-Gm-Message-State: APjAAAVO6rmXXMMyb/vY/0FyRkvaBG6FqO5b3voFZssZVN0tPiUzpPNh BG+RJQv/zheyOobE5qbFNp0oLzdJDWPJdf4c X-Google-Smtp-Source: APXvYqwTeN//kJ1VzHs+IZ3/FxWs+oMkXXPMbNniD7w8DnAWAJiZObdSFyxdhTnhevVqfDCXTeaPnw== X-Received: by 2002:ad4:5586:: with SMTP id e6mr18397573qvx.92.1579483360886; Sun, 19 Jan 2020 17:22:40 -0800 (PST) Original-Received: from [192.168.1.5] (c-174-60-229-153.hsd1.pa.comcast.net. [174.60.229.153]) by smtp.gmail.com with ESMTPSA id x126sm15226395qkc.42.2020.01.19.17.22.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Jan 2020 17:22:40 -0800 (PST) In-Reply-To: <83h80rxlae.fsf@gnu.org> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::f42 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:244401 Archived-At: --Apple-Mail=_7CD5F7EF-945D-497E-B87A-37BEDB959EA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > I mean when gdb-display-source-buffer will fail to find the source > window? I dug into gud.el and gdb-mi.el to see what=E2=80=99s really going on. = It=E2=80=99s not very straightforward. Let me present my understanding = of the logic below. Please correct me if I=E2=80=99m wrong. First, =E2=80=9Cframe=E2=80=9D in gud is a cons of file name and line, = basically at where gdb stops (file:line). When gud needs to display the current line at where gdb stops at = (=E2=80=9Cframe=E2=80=9D), it tries to display it in a new window if the = target buffer is not already shown. `gud-last-frame` is set to the frame = we want to display, and we call `gud-display-frame` to display it. = `gud-display-frame` calls `gud-display-line` calls `display-buffer` with = `(inhibit-same-window . t)`. Then it sets `gud-last-last-frame` to the = frame just displayed, and `gdb-last-frame` to nil. So `last-frame` is = basically the frame to be displayed, and `last-last-frame` is the last = displayed frame. As for gdb-mi, in `gdb-display-source-buffer`, it first looks for the = window displaying `gud-last-last-frame` (last displayed frame, that is). = If that doesn=E2=80=99t exist, it looks for `gdb-source-window` and use = that. Either way it sets the window found to `gdb-source-window`. And it = returns nil if no last-last-frame window nor `gdb-source-window` is = found. How can `gdb-source-window` be set? There are two ways, 1) when = gdb-mi starts with many-windows or show-main option, it opens a source = window and set that to `gdb-source-window`, 2) if = `gdb-display-source-window` finds a window displaying = `gud-last-last-frame`, that window will be set to `gdb-source-window`.=20= Gdb-mi also uses `gud-display-frame`: when I type commands in comint = buffer, the result from gdb is handled by `gdb-frame-handler`, which = sets `gud-last-frame` and calls `gud-display-frame`. So, commands like step, next, etc, uses `gud-display-frame`. Except that = `gdb-goto-breakpoint` uses gdb-display-source. So it seems the intension is to display source in new window, not using = only one window as I originally thought. I=E2=80=99d like to simplify = it, put the decision logic into one place. And then we can add = customizability to it. >> It shouldn't harm to try that. I'd still make it optional - maybe >> someone wants to see the other buffers. >>=20 >> I tend to agree with the last bit. >>=20 >> At the very least I want to fix the inconsistency in gdb-mi =E2=80=94 = goto-breakpoint uses `(or >> gdb-display-source-buffer display-buffer)` and gud-display-line uses = `display-buffer`. We can modify the >> display logic to allow user customization once gdb-mi is consistent = within itself. >=20 > Let's add a defcustom to control this new behavior. Do you mean options like `only-one-window`, `switch-between-two`, = `as-much-as-possible`? Yuan --Apple-Mail=_7CD5F7EF-945D-497E-B87A-37BEDB959EA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I mean when gdb-display-source-buffer will fail to find the = source
window?

I dug into gud.el and gdb-mi.el to see what=E2=80=99= s really going on. It=E2=80=99s not very straightforward. Let me present = my understanding of the logic below. Please correct me if I=E2=80=99m = wrong.

First, =E2=80=9Cframe=E2=80=9D = in gud is a cons of file name and line, basically at where gdb stops = (file:line).

When gud needs to = display the current line at where gdb stops at (=E2=80=9Cframe=E2=80=9D), = it tries to display it in a new window if the target buffer is not = already shown. `gud-last-frame` is set to the frame we want to display, = and we call `gud-display-frame` to display it. `gud-display-frame` calls = `gud-display-line` calls `display-buffer` with `(inhibit-same-window . = t)`. Then it sets `gud-last-last-frame` to the frame just displayed, and = `gdb-last-frame` to nil. So `last-frame` is basically the frame to be = displayed, and `last-last-frame` is the last displayed = frame.

As for gdb-mi, in = `gdb-display-source-buffer`, it first looks for the window displaying = `gud-last-last-frame` (last displayed frame, that is). If that doesn=E2=80= =99t exist, it looks for `gdb-source-window` and use that. Either way it = sets the window found to `gdb-source-window`. And it returns nil if no = last-last-frame window nor `gdb-source-window` is found. How can = `gdb-source-window` be set? There are two ways, 1) when gdb-mi starts = with many-windows or show-main option, it opens a source window and set = that to `gdb-source-window`, 2) if `gdb-display-source-window` finds a = window displaying `gud-last-last-frame`, that window will be set to = `gdb-source-window`. 

Gdb-mi = also uses `gud-display-frame`: when I type commands in comint buffer, = the result from gdb is handled by `gdb-frame-handler`, which sets = `gud-last-frame` and calls `gud-display-frame`.

So, commands like step, next, etc, uses = `gud-display-frame`. Except that `gdb-goto-breakpoint` uses = gdb-display-source.

So it seems the = intension is to display source in new window, not using only one window = as I originally thought. I=E2=80=99d like to simplify it, put the = decision logic into one place. And then we can add customizability to = it.

It shouldn't harm to try that. =  I'd still make it optional - maybe
someone wants to = see the other buffers.

I tend to agree with = the last bit.

At the very least I want to = fix the inconsistency in gdb-mi =E2=80=94 goto-breakpoint uses `(or
gdb-display-source-buffer display-buffer)` and = gud-display-line uses `display-buffer`. We can modify the
display logic to allow user customization once gdb-mi is = consistent within itself.

Let's add a defcustom to control this new = behavior.

Do you mean options like `only-one-window`, = `switch-between-two`, `as-much-as-possible`?

Yuan

= --Apple-Mail=_7CD5F7EF-945D-497E-B87A-37BEDB959EA8--