Completion on symbols nonfunctional, gdb 7.8.1

Completion on symbols nonfunctional, gdb 7.8.1

[Jonah Petri]

Hello!
Does anyone know why some gdbs (in this case 7.8.1, as built into a
yocto sdk) might not have working tab completion?

If I type "break wr" and then press <tab>, it does nothing.  However
gdb does know about the symbols!  To wit, if I type:
(gdb) complete b wr<return>
b write
b write@got.plt
b write@plt
b writer.h

So, the completions are there, but something is not hooked up
properly... Strangely, it seems that the tab key is hooked up to
something, as when I press <tab> from an empty gdb prompt, I get lots
of good completions, like "actions", "add-auto-load-safe-path", etc.
However, completion on symbols, like "write" above, seems to not work.

I never realized how much I depend on tab completion for productivity
while debugging, so any help would be much appreciated!

Thanks!
Jonah

Re: Completion on symbols nonfunctional, gdb 7.8.1

[Maciej W. Rozycki]

On Mon, 29 Feb 2016, Jonah Petri wrote:

> Does anyone know why some gdbs (in this case 7.8.1, as built into a
> yocto sdk) might not have working tab completion?

 Does "some" mean different versions installed on the same system or 
across different computers?  If the latter, then have you checked for 
anything odd in /etc/inputrc or ~/.inputrc first?  Distributions tend to 
put weird stuff there, which is bound to break someone's assumptions.

  Maciej

Re: Completion on symbols nonfunctional, gdb 7.8.1

[Jonah Petri]

On Mon, Feb 29, 2016 at 11:54 AM, Maciej W. Rozycki
<macro@linux-mips.org> wrote:
> On Mon, 29 Feb 2016, Jonah Petri wrote:
>
>> Does anyone know why some gdbs (in this case 7.8.1, as built into a
>> yocto sdk) might not have working tab completion?
>
>  Does "some" mean different versions installed on the same system or
> across different computers?  If the latter, then have you checked for
> anything odd in /etc/inputrc or ~/.inputrc first?  Distributions tend to
> put weird stuff there, which is bound to break someone's assumptions.
>

Sorry for not being specific.  What I mean is that we consistently see
this behavior across all of our systems, which are all running
identical software, including gdb 7.8.1.  This probably isn't
surprising :)

I should also mention that we're running gdb as root.  Not sure if that matters.

I'm not familiar with inputrc, unfortunately.  Can you tell me if
there's anything weird in there?  I have nothing in ~root/.inputrc,
but here's the contents of /etc/inputrc:

# /etc/inputrc - global inputrc for libreadline
# See readline(3readline) and `info rluserman' for more information.

# Be 8 bit clean.
set input-meta on
set output-meta on

# To allow the use of 8bit-characters like the german umlauts, comment out
# the line below. However this makes the meta key not work as a meta key,
# which is annoying to those which don't need to type in 8-bit characters.

# set convert-meta off

# try to enable the application keypad when it is called.  Some systems
# need this to enable the arrow keys.
# set enable-keypad on

# see /usr/share/doc/bash/inputrc.arrows for other codes of arrow keys

# do not bell on tab-completion
# set bell-style none

# some defaults / modifications for the emacs mode
$if mode=emacs

# allow the use of the Home/End keys
# "\e[1~": beginning-of-line
# "\e[4~": end-of-line

# allow the use of the Delete/Insert keys
# "\e[3~": delete-char
# "\e[2~": quoted-insert

# mappings for "page up" and "page down" to step to the beginning/end
# of the history
# "\e[5~": beginning-of-history
# "\e[6~": end-of-history

# alternate mappings for "page up" and "page down" to search the history
# "\e[5~": history-search-backward
# "\e[6~": history-search-forward

# # mappings for Ctrl-left-arrow and Ctrl-right-arrow for word moving
# "\e[5C": forward-word
# "\e[5D": backward-word
# "\e\e[C": forward-word
# "\e\e[D": backward-word

# $if term=rxvt
# "\e[8~": end-of-line
# $endif

# for non RH/Debian xterm, can't hurt for RH/DEbian xterm
# "\eOH": beginning-of-line
# "\eOF": end-of-line

# for freebsd console
# "\e[H": beginning-of-line
# "\e[F": end-of-line

$endif

Re: Completion on symbols nonfunctional, gdb 7.8.1

[Maciej W. Rozycki]

On Mon, 29 Feb 2016, Jonah Petri wrote:

> I'm not familiar with inputrc, unfortunately.  Can you tell me if
> there's anything weird in there?  I have nothing in ~root/.inputrc,
> but here's the contents of /etc/inputrc:

 Me neither offhand; see readline(3) for details.  Local settings take 
precedence over global ones, so try making an empty ~/.inputrc file to see 
if the symptoms go away.

 FWIW I have these settings in my ~/.inputrc file:

set convert-meta on
M-C-i: dynamic-complete-history
Meta-s: forward-search-history

and I have never really bothered to examine the global settings forced 
upon me by the distribution.  I found them disturbing in surprising ways, 
breaking my habits developed with `readline' over more than 20 years.

  Maciej

Re: Completion on symbols nonfunctional, gdb 7.8.1

[Jonah Petri]

On Mon, Feb 29, 2016 at 12:44 PM, Maciej W. Rozycki
<macro@linux-mips.org> wrote:
> On Mon, 29 Feb 2016, Jonah Petri wrote:
>
>> I'm not familiar with inputrc, unfortunately.  Can you tell me if
>> there's anything weird in there?  I have nothing in ~root/.inputrc,
>> but here's the contents of /etc/inputrc:
>
>  Me neither offhand; see readline(3) for details.  Local settings take
> precedence over global ones, so try making an empty ~/.inputrc file to see
> if the symptoms go away.
>

Thanks for the advice!  Your hints led me to readline, which seems to
be the problem.  I seem to be linking against a bad readline lib.  I
recompiled gdb with --without-system-readline, and now all is as
expected.

Thanks again.

Re: Completion on symbols nonfunctional, gdb 7.8.1

[Maciej W. Rozycki]

On Mon, 29 Feb 2016, Jonah Petri wrote:

> Thanks for the advice!  Your hints led me to readline, which seems to
> be the problem.  I seem to be linking against a bad readline lib.  I
> recompiled gdb with --without-system-readline, and now all is as
> expected.
> 
> Thanks again.

 I'm glad to be of help.

  Maciej