Python/GDB compatibility issues about gdb-dashboard HOT 21 CLOSED

Actually, overcoming the lack of gdb.COMPLETE_EXPRESSION is quite easy, just create a .py file in the ~/.gdbinit.d/ directory with the following line:

gdb.COMPLETE_EXPRESSION = gdb.COMPLETE_SYMBOL

Unfortunately the stack default module uses gdb.FrameDecorator which is missing in GDB 7.6.
Now, I realize that I could include that class from the GDB repo in order to make it work, but quite frankly I don't think that would be a good idea.

A quick fix for that would be adding FrameDecorator.py within ~/.gdbinit.d/ then patching things up:

python
import imp
gdb.FrameDecorator = imp.new_module('FrameDecorator')
gdb.FrameDecorator.FrameDecorator = FrameDecorator
end

Here's a dirty script which should automatize all the grunt work:

mkdir -p ~/.gdbinit.d/
wget 'https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gdb/python/lib/gdb/FrameDecorator.py' -O ~/.gdbinit.d/FrameDecorator.py
sed -i '1s/^/python gdb.COMPLETE_EXPRESSION = gdb.COMPLETE_SYMBOL\n/' .gdbinit
cat >>.gdbinit <<EOF
python
import imp
gdb.FrameDecorator = imp.new_module('FrameDecorator')
gdb.FrameDecorator.FrameDecorator = FrameDecorator
end
EOF

from gdb-dashboard.

Same error on Debian (full output on issue #2, closed in favor of this issue.)

from gdb-dashboard.

The lack of subprocess.check_output is a minor issue, but I need to figure out why does COMPLETE_EXPRESSION is missing, yet it is documented here.

I'll investigate this. Thanks both for reporting.

from gdb-dashboard.

@cyrus-and I got some clue. Looks like COMPLTE_EXPRESSION was added from gdb patch 15747 (https://sourceware.org/ml/gdb-patches/2013-09/msg00583.html), which was later incorporated to gdb release branch 7.7.

Unfortunately, CentOS 7 (the latest version), and some other mainstream linux distros, use gdb 7.6, or ever older versions.

from gdb-dashboard.

@fanbin yes that's the point, thanks.

For what concern Python 2.6 unfortunately there are a lot of other things that are not supported. I will fix problems with old GDB versions but still I don't feel like to refactor the code to support Python 2.6, at least for the moment being.

from gdb-dashboard.

Confirmed the fix works. I also recommend compiling new gdb 7.10 with python 2.7, which are easy and short compiling with make -j

from gdb-dashboard.

I compile and install the GDB 7.7 in my CentOS6.5

I'm using python2.6 as the default python in my CentOS6.5, and didn't update any of the package since I got no access to the internet, so I manually compile (using GDB7.7) and install python2.7 and python3.3 into /usr/local, and the default python version is still 2.6 since the a lot of pacakges still need it.

How can I use the python2.7 or python3.3 which lie in /usr/local/bin in .gdbinit?

from gdb-dashboard.

The Python version used by GDB (and thus by GDB dashboard) is not the default version in your system, it is the one chosen at compilation time. So you have to recompile it with the proper option, e.g.:

./configure --with-python=$(which python3.3)

You can check the Python version used by GDB before installing with (from the source directory):

./gdb/gdb -ex 'python import sys; print(sys.version)' -ex quit

from gdb-dashboard.

Thank you, it works.

from gdb-dashboard.

using the instructions here i got i got it to work on gdb 7.6, however there's one oddity:
the command prompt (previously (gdb)) is now replaced by

[1;35m>>>[0m

(it's printed literally like that). something seems to be wrong with the code that prints the escape sequence. note that the colors in other parts of the screen work fine, only the prompt is affected. the rev. i use is 7c70149 (current HEAD).

from gdb-dashboard.

@rofl0r That's weird indeed, what's the Python version linked with GDB?

I have a GDB 7.6 setup linked with Python 2.7 which, apart from the aforementioned COMPLETE_EXPRESSION error (due to GDB 7.6), seems to work fine. At least for what concerns the prompt...

Try starting GDB with -nx option and issue the following command:

python gdb.prompt_hook = lambda _: gdb.prompt.substitute_prompt('\[\e[1;35m\]>>>\[\e[0m\] ')

This is more or less what GDB dashboard does; you should end up with the magenta ">>>" prompt as in the screenshot.

from gdb-dashboard.

it's gdb 7.6.2 linked against python 2.7.10 and libedit as a drop-in replacement for readline (because it's smaller), i suspect that's what makes the difference.
doing as you said above gives me the same prompt than earlier,i.e. [1;35m>>>[0m

from gdb-dashboard.

i suspect that's what makes the difference.

@rofl0r Yeah, I think that too. You can try to customize the default prompt so to not use escape sequences, for example:

dashboard -style prompt_running '[on]$'
dashboard -style prompt_not_running '[off]$'

Alternatively just use a static prompt string:

dashboard -style prompt '$'

from gdb-dashboard.

i am running gdb 7.7 with python 2.7.4 i am getting error

Cannot write the dashboard: 'ascii' codec can't encode characters in position 5-7: ordinal not in range(128)

from gdb-dashboard.

@mohit3112 is there any chance that I can reproduce that on my PC?

Edit: The latest revision prints additional information, can you please post the entire stacktrace?

from gdb-dashboard.

@cyrus-and
Cannot write the dashboard
Traceback (most recent call last):
File "", line 357, in render
UnicodeEncodeError: 'ascii' codec can't encode characters in position 5-7: ordinal not in range(128)

from gdb-dashboard.

@mohit3112 let's continue the discussion in #50

from gdb-dashboard.

I'm still having the issue with "COMPLETE_EXPRESSION", it seems that it can be ignored - but the wiki has nothing about that in.

For reference:

> source ~/gdb-dashboard
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<string>", line 582, in start
  File "<string>", line 465, in load_modules
  File "<string>", line 706, in __init__
  File "<string>", line 732, in add_subcommands
  File "<string>", line 2116, in commands
AttributeError: 'module' object has no attribute 'COMPLETE_EXPRESSION'
~/gdb-dashboard:2267: Error in sourced command file:
Error while executing Python code.

... and when a breakpoint is actually reached:

âââ Output/messages ââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".

Breakpoint 1, 0x00007fffe7db2279 in TESTME () at /tmp/TEST.cob:51
51             S000-00.
âââ Assembly âââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
Traceback (most recent call last):
  File "<string>", line 542, in render
  File "<string>", line 1370, in lines
  File "<string>", line 372, in fetch_breakpoints
AttributeError: 'gdb.Breakpoint' object has no attribute 'temporary'
âââ Breakpoints ââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
Traceback (most recent call last):
  File "<string>", line 542, in render
  File "<string>", line 2182, in lines
  File "<string>", line 372, in fetch_breakpoints
AttributeError: 'gdb.Breakpoint' object has no attribute 'temporary'
ââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
>>>

from gdb-dashboard.

@GitMensch have you tried the workaround described here?

from gdb-dashboard.

Workaround works (I've used an older version of the Framefilter). I primarily missed to see that...

One note: I think it would be reasonable to not download the most current FrameDecorator.py but instead use the "locked" version from GDB 7.7.
For this to work change the wget URL to download https://sourceware.org/git/?p=binutils-gdb.git;a=blob_plain;f=gdb/python/lib/gdb/FrameDecorator.py;hb=fe284cd86ba9761655a9281fef470d364e27eb85 instead of "download the newest version which is not unlikely to break your GDB 7.6 / install sometimeTM".

from gdb-dashboard.

@GitMensch good point, thanks! I updated the wiki.

from gdb-dashboard.