* [PATCH] Fix 5-line offset of edit command @ 2023-02-11 10:08 Gary Johnson 2023-02-11 10:58 ` Eli Zaretskii 0 siblings, 1 reply; 5+ messages in thread From: Gary Johnson @ 2023-02-11 10:08 UTC (permalink / raw) To: gdb When gdb is paused at a line and I open the current file with the edit command, gdb uses vim to open the file at the current line, but the line number given to vim is always too high by 5. For example, using gdb-12.1 and the gdb-12.1 source, cd to gdb-12.1/gdb and run gdb on itself. $ gdb gdb (gdb) b main (gdb) run Gdb will stop at line 25. (gdb) edit will open vim at line 30. Executing :ps -fH confirms that vim was started with the argument "+30". The problem appears to be in the edit_command() function in cli-cmds.c, at line 966 in version 12.1. The solution is to delete that line. The patch is below. Regards, Gary -------------------------------------------------------------------- --- cli-cmds.c.orig 2022-05-01 11:46:31.000000000 -0700 +++ cli-cmds.c 2023-02-11 00:54:01.695108617 -0800 @@ -963,7 +963,6 @@ { if (sal.symtab == 0) error (_("No default source file yet.")); - sal.line += get_lines_to_list () / 2; } else { ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Fix 5-line offset of edit command 2023-02-11 10:08 [PATCH] Fix 5-line offset of edit command Gary Johnson @ 2023-02-11 10:58 ` Eli Zaretskii 2023-02-11 22:52 ` Gary Johnson 0 siblings, 1 reply; 5+ messages in thread From: Eli Zaretskii @ 2023-02-11 10:58 UTC (permalink / raw) To: Gary Johnson; +Cc: gdb > Date: Sat, 11 Feb 2023 02:08:14 -0800 > From: Gary Johnson <garyjohn@spocom.com> > > When gdb is paused at a line and I open the current file with the > edit command, gdb uses vim to open the file at the current line, but > the line number given to vim is always too high by 5. > > For example, using gdb-12.1 and the gdb-12.1 source, cd to > gdb-12.1/gdb and run gdb on itself. > > $ gdb gdb > (gdb) b main > (gdb) run > > Gdb will stop at line 25. > > (gdb) edit > > will open vim at line 30. Executing > > :ps -fH > > confirms that vim was started with the argument "+30". > > The problem appears to be in the edit_command() function in > cli-cmds.c, at line 966 in version 12.1. The solution is to > delete that line. The patch is below. This is probably editor-specific? But I admit I cannot understand that addition, either. I could understand if we were _subtracting_ half the number of lines to list, for those editors which place the line at the top of the display. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Fix 5-line offset of edit command 2023-02-11 10:58 ` Eli Zaretskii @ 2023-02-11 22:52 ` Gary Johnson 2023-02-12 6:14 ` Eli Zaretskii 0 siblings, 1 reply; 5+ messages in thread From: Gary Johnson @ 2023-02-11 22:52 UTC (permalink / raw) To: gdb On 2023-02-11, Eli Zaretskii wrote: > > Date: Sat, 11 Feb 2023 02:08:14 -0800 > > From: Gary Johnson <garyjohn@spocom.com> > > > > When gdb is paused at a line and I open the current file with the > > edit command, gdb uses vim to open the file at the current line, but > > the line number given to vim is always too high by 5. > > > > For example, using gdb-12.1 and the gdb-12.1 source, cd to > > gdb-12.1/gdb and run gdb on itself. > > > > $ gdb gdb > > (gdb) b main > > (gdb) run > > > > Gdb will stop at line 25. > > > > (gdb) edit > > > > will open vim at line 30. Executing > > > > :ps -fH > > > > confirms that vim was started with the argument "+30". > > > > The problem appears to be in the edit_command() function in > > cli-cmds.c, at line 966 in version 12.1. The solution is to > > delete that line. The patch is below. > > This is probably editor-specific? No, it's not editor-specific. The command to run the editor is created at the end of the edit_command() function: if ((editor = getenv ("EDITOR")) == NULL) editor = "/bin/ex"; fn = symtab_to_fullname (sal.symtab); /* Quote the file name, in case it has whitespace or other special characters. */ gdb::unique_xmalloc_ptr<char> p = xstrprintf ("%s +%d \"%s\"", editor, sal.line, fn); shell_escape (p.get (), from_tty); Specifying the line number to jump to after opening a file by prefixing the line with a + was standard with early Unix editors and I think most editors today still support it for compatibility with programs such as gdb. > But I admit I cannot understand that addition, either. I could > understand if we were _subtracting_ half the number of lines to list, > for those editors which place the line at the top of the display. Maybe in some other situation, but not in the situation where the user wants to open an external editor _at_ a specific line. As I recall, this used to work long ago, then something changed and the editor was always opened at line 6, then around 2020 it changed again to open at the current line plus 5. I suspect a copy-and-paste error, but I haven't looked into the history of that function. I intended to send this to gdb-patches, but it looks like I wasn't paying attention to the address and sent it to the general gdb list instead. Regards, Gary ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Fix 5-line offset of edit command 2023-02-11 22:52 ` Gary Johnson @ 2023-02-12 6:14 ` Eli Zaretskii 2023-02-12 9:23 ` Andreas Schwab 0 siblings, 1 reply; 5+ messages in thread From: Eli Zaretskii @ 2023-02-12 6:14 UTC (permalink / raw) To: Gary Johnson; +Cc: gdb > Date: Sat, 11 Feb 2023 14:52:33 -0800 > From: Gary Johnson <garyjohn@spocom.com> > > > > The problem appears to be in the edit_command() function in > > > cli-cmds.c, at line 966 in version 12.1. The solution is to > > > delete that line. The patch is below. > > > > This is probably editor-specific? > > No, it's not editor-specific. The command to run the editor is > created at the end of the edit_command() function: I meant the effect is editor-specific. IOW, what exactly does each editor display when passed a line number. > As I recall, this used to work long ago, then something changed and > the editor was always opened at line 6, then around 2020 it changed > again to open at the current line plus 5. I suspect > a copy-and-paste error, but I haven't looked into the history of > that function. I tried to look into the history with "git log -L", but got stuck at the commit that moved the function from another file. Maybe some Git expert could suggest how to cross that line? > I intended to send this to gdb-patches, but it looks like I wasn't > paying attention to the address and sent it to the general gdb list > instead. Yes, it is best to resent to gdb-patches. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Fix 5-line offset of edit command 2023-02-12 6:14 ` Eli Zaretskii @ 2023-02-12 9:23 ` Andreas Schwab 0 siblings, 0 replies; 5+ messages in thread From: Andreas Schwab @ 2023-02-12 9:23 UTC (permalink / raw) To: Eli Zaretskii via Gdb; +Cc: Gary Johnson, Eli Zaretskii On Feb 12 2023, Eli Zaretskii via Gdb wrote: > I tried to look into the history with "git log -L", but got stuck at > the commit that moved the function from another file. Maybe some Git > expert could suggest how to cross that line? There is no preceding history. The command was added in that commit. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-02-12 9:23 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-02-11 10:08 [PATCH] Fix 5-line offset of edit command Gary Johnson 2023-02-11 10:58 ` Eli Zaretskii 2023-02-11 22:52 ` Gary Johnson 2023-02-12 6:14 ` Eli Zaretskii 2023-02-12 9:23 ` Andreas Schwab
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).