Re: [RFD]: deprecate the "fg" command

[Stan Shebs <shebs@apple.com>]

Michael Snyder wrote:
> 
> Does anybody use the "fg" command (a synonym for continue)?
> It's been in there since 1991, but never documented.  I'd like to
> deprecate it to reduce clutter and the hazard of dangerous typos.
> If you tried to say "f" (the frame command) and your finger hit
> two keys by accident, the result would be an unintentional continue,
> which is generally a bad thing.

I'm agreeable.  In fact, I think we discussed using "fg" and "bg" as
commands to control multiple processes for when we implemented
multiple-process-debugging, in which case having fg mean something
else already would be bad.

Stan
From ac131313@cygnus.com Sat May 27 02:11:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Online PDF docs
Date: Sat, 27 May 2000 02:11:00 -0000
Message-id: <392F9129.F685F7A5@cygnus.com>
X-SW-Source: 2000-05/msg00144.html
Content-length: 244

FYI,

I've added a PDF version of the GDB 5.0.++ documentation (it includes
two bug fixes) under:

http://sourceware.cygnus.com/gdb/5/onlinedocs/

Hopefully the nightly generated online doco will also shortly be
available in PDF also.

	Andrew
From rearnsha@arm.com Sat May 27 10:47:00 2000
From: Richard Earnshaw <rearnsha@arm.com>
To: gdb@sourceware.cygnus.com
Cc: rearnsha@arm.com, scottb@netwinder.org
Subject: ARM/linux gdb stops and gives no info
Date: Sat, 27 May 2000 10:47:00 -0000
Message-id: <200005271746.SAA19744@cam-mail2.cambridge.arm.com>
X-SW-Source: 2000-05/msg00145.html
Content-length: 2095

Using the gdb-5.0 rpm from ftp://ftp.netwinder.org/users/s/scottb/current/g
db-5.0-1nw1.armv4l.rpm
(which I believe is a straight build of the gdb-5.0 sources for the 
netwinder),  I hit the following problem while trying to debug cc1plus on 
a Netwinder box.

$ gdb cc1plus
GNU gdb 5.0 (UI_OUT)
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you 
are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "armv4l-unknown-linux-gnu"...
Breakpoint 1 at 0x2001278
Breakpoint 2 at 0x20711d0: file /net/home/rearnsha/gnusrc/egcs/gcc/rtl.c, 
line 1261.
Breakpoint 3 at 0x2001048
(gdb) run -O2 -fPIC t.i
Starting program: /home/rearnsha/gnu/egcs/gcc/cc1plus -O2 -fPIC t.i
Breakpoint 1 at 0x4004947c: file exit.c, line 40.
Breakpoint 3 at 0x40048110: file ../sysdeps/generic/abort.c, line 55.
During symbol reading...register number 258 too large (max 26) in symbol 
buf...
type_info::~type_info ()bool type_info::operator== (const type_info &) 
constvoid __rtti_class (void *, const char *, const 
__class_type_info::base_info *, unsigned int)void __rtti_si (void *, const 
char *, const type_info *)void __rtti_user (void *, const char *)int 
__user_type_info::upcast (const type_info &, void *, void **) constvoid 
*__user_type_info::dyncast (int, const type_info &, void *, const 
type_info &, void *) const
Program received signal SIGSEGV, Segmentation fault.
Cannot access memory at address 0x0
(gdb) where
Cannot access memory at address 0x0
(gdb) info reg 
No selected frame.
(gdb) 

There seems to be nothing I can do to get gdb to tell me what happened.

I get the same problem with a gdb I've built direct from the sources 
(though I had some local mods in that code)...

I can understand not being able to unpick the stack frame if I've jumped 
to never-never land, but to not even be able to display the registers 
makes the debugger useless.

R.