I get a strange behavior of GDB debugger when I launch it from MSYS2’s MINGW.
What I got
When I press any arrow key on keyboard, cursor is moved inside the shell window. For example, if I press Up key, GDB doesn't show the last command I typed. But instead text cursor is moved up by one line. Left arrow moves cursor to the left. And so on. Home key always moves cursor to the left top corner of the terminal window; End key moves cursor to the beginning of the current line and then moves cursor one line up.
I can't create a breakpoint at a dynamically loaded library’s code. For example, assuming that file 'cvtimpl.cxx' is a part of library code, command break cvtimpl.cxx:362
ends up with this: No source file named cvtimpl.cxx. Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
I mean I can't answer to "Make breakpoint pending on future shared library load?" question – GDB automatically answers "[answered N; input not from terminal]".
Thus, I have to use set breakpoint pending on command.
What I do:
Launch MINGW using msys2_shell.cmd -mingw64,
Launch GDB using gdb -se some.exe
What software version I have:
Windows 7 and 10,
GDB 7.11.1,
MSYS2/MINGW runtime is up to date.
If I run GDB from Windows native ‘cmd’ shell, GDB works fine, just as expected/documented.
Therefore, my question is: does a way exist I can use GDB normally when GDB was launched from MSYS2’s MINGW?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As a work-around, there are lots of front-ends which are far less painful than the command line IMO. CodeLite, CodeBlocks, QTCreator, CLion, etc. work with MSYS2 and MinGW
pacman –S –needed mingw-w64-x86_64-codelite-git
From: Ruslan Garipov [mailto:ruslangaripov@users.sf.net]
Sent: Thursday, August 18, 2016 4:35 AM
To: [msys2:discussion]general@discussion.msys2.p.re.sf.net
Subject: [msys2:discussion] GDB on MSYS2’s MINGW-w64 shell: unwanted behavior
I get a strange behavior of GDB debugger when I launch it from MSYS2’s MINGW.
What I got
When I press any arrow key on keyboard, cursor is moved inside the shell window. For example, if I press Up key, GDB doesn't show the last command I typed. But instead text cursor is moved up by one line. Left arrow moves cursor to the left. And so on. Home key always moves cursor to the left top corner of the terminal window; End key moves cursor to the beginning of the current line and then moves cursor one line up.
I can't create a breakpoint at a dynamically loaded library’s code. For example, assuming that file 'cvtimpl.cxx' is a part of library code, command
break cvtimpl.cxx:362
ends up with this:
No source file named cvtimpl.cxx.
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
I mean I can't answer to "Make breakpoint pending on future shared library load?" question – GDB automatically answers "[answered N; input not from terminal]".
Thus, I have to use set breakpoint pending on command.
What I do:
Launch MINGW using msys2_shell.cmd -mingw64,
Launch GDB using gdb -se some.exe
What software version I have:
Windows 7 and 10,
GDB 7.11.1,
MSYS2/MINGW runtime is up to date.
If I run GDB from Windows native ‘cmd’ shell, GDB works fine, just as expected/documented.
Therefore, my question is: does a way exist I can use GDB normally when GDB was launched from MSYS2’s MINGW?
I get a strange behavior of GDB debugger when I launch it from MSYS2’s MINGW.
What I got
break cvtimpl.cxx:362
ends up with this:
No source file named cvtimpl.cxx.
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
I mean I can't answer to "Make breakpoint pending on future shared library load?" question – GDB automatically answers "[answered N; input not from terminal]".
Thus, I have to use
set breakpoint pending on
command.What I do:
msys2_shell.cmd -mingw64
,gdb -se some.exe
What software version I have:
If I run GDB from Windows native ‘cmd’ shell, GDB works fine, just as expected/documented.
Therefore, my question is: does a way exist I can use GDB normally when GDB was launched from MSYS2’s MINGW?
As a work-around, there are lots of front-ends which are far less painful than the command line IMO. CodeLite, CodeBlocks, QTCreator, CLion, etc. work with MSYS2 and MinGW
pacman –S –needed mingw-w64-x86_64-codelite-git
From: Ruslan Garipov [mailto:ruslangaripov@users.sf.net]
Sent: Thursday, August 18, 2016 4:35 AM
To: [msys2:discussion] general@discussion.msys2.p.re.sf.net
Subject: [msys2:discussion] GDB on MSYS2’s MINGW-w64 shell: unwanted behavior
I get a strange behavior of GDB debugger when I launch it from MSYS2’s MINGW.
What I got
break cvtimpl.cxx:362
ends up with this:
No source file named cvtimpl.cxx.
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
I mean I can't answer to "Make breakpoint pending on future shared library load?" question – GDB automatically answers "[answered N; input not from terminal]".
Thus, I have to use set breakpoint pending on command.
What I do:
What software version I have:
If I run GDB from Windows native ‘cmd’ shell, GDB works fine, just as expected/documented.
Therefore, my question is: does a way exist I can use GDB normally when GDB was launched from MSYS2’s MINGW?
GDB on MSYS2’s MINGW-w64 shell: unwanted behavior https://sourceforge.net/p/msys2/discussion/general/thread/0f85b448/?limit=25#eb1e
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/msys2/discussion/general/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
It's a known problem with mintty. You could try using winpty to wrap gdb.
More here:
https://github.com/mintty/mintty/issues/56
https://sourceforge.net/p/msys2/wiki/Terminals/
@David
Thanks, David! Links you've provided are very helpful.
The answer is here: https://github.com/mintty/mintty/issues/380
Actually I have searched for non-mingw version of gdb package, but unfortunately I overlooked it.