wh command without argument to gdb in Emacs shell buffer == utter confusion
wh command without argument to gdb in Emacs shell buffer Running gdb in Emacs's shell-mode buffer and then issueing wh without argument by mistake causes GDB to get hung (without no visible activity) [or rathr print long blank lines without prompt!?] I am perplexed as to what is going on as I uncover a few things along the way. Below, a log is excerpted. --- Note 1: I am NOT using Emacs's gdb-mode when this happens. I type gdb as an ordinary shell command within the Emacs's shell buffer. Note 2: Background. In the old days, wh would be considered a shorthand for where command. But today there is winheight command and wh is regarded as a shorthand for it. An old timer like me types wh as a shorthand for where without argument, and noticed this strange problem. After a few days of pondering and trying to fix various issues like missing shared library symbols, etc., finally I got curious and typed help wh and found out about this winheight command. So I was typing winheight command instead of where all along. Note 3: If I use gdb in an ordinary terminal screen, say, without argument and type wh to gdb prompt, $ gdb gdb wh I get a small popup window, and in this case, it says, No source available and the usage help is printed to the original tty console where gdb prompt appears, and prompt returns. [I mistook this popup window as a X window, but no, it seems it is a text rectangle created by termcap library or similar! This is a source of confusion on my analysis. This confusion is in this writeup.] That is good. In emacs's shell-buffer usage, there is no indication of either (no window, no help message to the prompt. Well, control-C does not seem to work, but please read the excerpt log #2 at the end.) To wit, here is the log from within Emacs's shell buffer. The first run of gdb simply prints the help message for wh and quits. The second run gets hung after I type wh. [Ugh! No, as I write this message, I got still wiser and hit C-MC-J to this seemingly hung gdb and I got gdb prompt again. What is going on? More in the Log #2 at the end.] Log 1: --- begin quote --- ishikawa@debian-vbox-ci:/home/ishikawa$ gdb GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. (gdb) help wh Set the height of a specified window. Usage: winheight win_name [+ | -] #lines Window names are: src : the source window cmd : the command window asm : the disassembly window regs : the register display (gdb) quit ishikawa@debian-vbox-ci:/home/ishikawa$ gdb GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. (gdb) wh --- As you can see, control-C won't interrupt gdb. I have to kill gdb from another console. [But please read the log #2 excerpt at the end. It seems that there is another process running in a mixed manner in this terminal.] This is a major usability issue. Merely typing a command without an argument should not render gdb unusable. Yes, I think emacs might be setting up a strange environment for gdb, but gdb code should be ready for failing to open a X window, etc. TIA My Environment: gdb --version GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. ishikawa@debian-vbox-ci:/home/ishikawa$ emacs --version GNU Emacs 24.4.1 Copyright (C) 2014 Free Software Foundation, Inc. GNU Emacs comes with ABSOLUTELY NO WARRANTY. You may redistribute copies of Emacs under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. ishikawa@debian-vbox-ci:/home/ishikawa$ uname -a Linux debian-vbox-ci 3.2.0-4-686-pae #1 SMP Debian 3.2.57-3+deb7u2 i686 GNU/Linux OS Issue: The particular log was obtained
Re: wh command without argument to gdb in Emacs shell buffer == utter confusion
On 10/29/2014 05:10 AM, ishikawa wrote: $ env | grep TERM TERM=dumb TERMCAP= Right, we can reproduce this on the terminal with just: $ TERM=dumb gdb -q -nx (gdb) wh I'm working on a fix that will make GDB error out instead of hanging, like: $ TERM=dumb gdb -q -nx (gdb) wh Cannot enable the TUI: terminal doesn't support cursor addressing. (gdb) Thanks, Pedro Alves ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
The call stack can't include the right symbol for a weak symbol in dynamic library
Hi all,
I debug program with gdb on arm platform. The environment is as follow:
platform: vexpress(virtual app:ds:virtual machine app:ds:machine for
arm on qemu)
libc: uclibc
A error information happen when debug the next codes.
0xb6fa0440 in ?? () from /lib/libc.so.0
The call stack can't include the right symbol of function pause(); I
found that the function pause() is a weak symbol in dynamic library libc.
I don't know the reason why gdb can't get the right symbol from the
call stack? Is this error from gdb or uclibc.
Is there any suggestion about this error? I will be very grateful for
your any reply.
code:
relativedebug.c :
#include unistd.h
#include stdlib.h
#include signal.h
static void handler (int signo)
{
abort ();
}
int main (void)
{
signal (SIGALRM, handler);
alarm (1);
pause ();
pause ();
return 0;
}
-bash-4.2# '/usr/bin/'gdb relativedebug
delete breakpoints
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html http://gnu.org/licenses/gpl.html%3E%5EM
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as arm-euler-linux-gnueabi.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
http://www.gnu.org/software/gdb/bugs/%3E...%5EM
Reading symbols from /tmp/for_gdb_test/base_test/relativedebug...done.
(gdb) delete breakpoints
(gdb) break main
Breakpoint 1 at 0x8548: file relativedebug.c, line 30.
(gdb) run
Starting program: /tmp/for_gdb_test/base_test/relativedebug
Breakpoint 1, main () at relativedebug.c:30
30 signal (SIGALRM, handler);
(gdb) continue
Continuing.
Program received signal SIGABRT, Aborted.
0xb6fdb7f0 in raise () from /lib/libc.so.0
(gdb) bt
#0 0xb6fdb7f0 in raise () from /lib/libc.so.0
#1 0xb6fd5bf4 in abort () from /lib/libc.so.0^M
#2 0x8540 in handler (signo=14) at relativedebug.c:25^M
#3 signal handler called^M
#4 0xb6fa0440 in ?? () from /lib/libc.so.0
#5 0x8564 in main () at relativedebug.c:32
(gdb)
Thanks
Yan
___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: wh command without argument to gdb in Emacs shell buffer == utter confusion
Dear Pedro Alves, On 10/29/2014 05:10 AM, ishikawa wrote: $ env | grep TERM TERM=dumb TERMCAP= Right, we can reproduce this on the terminal with just: $ TERM=dumb gdb -q -nx (gdb) wh I'm working on a fix that will make GDB error out instead of hanging, like: $ TERM=dumb gdb -q -nx (gdb) wh Cannot enable the TUI: terminal doesn't support cursor addressing. (gdb) Thanks, Pedro Alves Thank you very much for your debugging effort. After learning about TUI, I thought disabling this feature based on the terminal capability would be one way to handle this issue. So your patch would be very much appreciated. Still being puzzled why I didn't realize this TUI feature for such a long time. It is not clear when TUI is enabled in Debian Package. It is possible it was not enabled even in the current release and only enabled in Jessie (experimental and the would be mainline release in the next release cycle). Thank you again. Best Regards, Chiaki Ishikawa ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: wh command without argument to gdb in Emacs shell buffer == utter confusion
On 10/29/2014 02:41 PM, ISHIKAWA,chiaki wrote: Thank you very much for your debugging effort. No problem. I use the TUI myself every day. FYI, the bug is fixed on mainline now: https://sourceware.org/ml/gdb-patches/2014-10/msg00798.html Still being puzzled why I didn't realize this TUI feature for such a long time. It is not clear when TUI is enabled in Debian Package. It is possible it was not enabled even in the current release and only enabled in Jessie (experimental and the would be mainline release in the next release cycle). No idea here. The TUI has been in GDB for ages. Thanks, Pedro Alves ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
