Python/GDB compatibility issues
fanbin opened this issue · 21 comments
Problem:
I tried to run gdb-dashboard on centos 6/7, but failed on both platforms.
Possible Reason:
It looks like centos 6's gdb uses python 2.6, which does not have subprocess.check_output supported, meanwhile centos 7 fails to work with the error as gdb module " 'module' object has no attribute 'COMPLETE_EXPRESSION' ".
Platform Information:
Centos 6's gdb links to python 2.7.6 and centos 6 links to python 2.6.6.
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.
@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.
@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.
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_SYMBOLUnfortunately 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
EOFConfirmed the fix works. I also recommend compiling new gdb 7.10 with python 2.7, which are easy and short compiling with make -j
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?
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
Thank you, it works.
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).
@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.
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
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 '$'
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)
@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?
@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)
@mohit3112 let's continue the discussion in #50
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'
ââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
>>>
@GitMensch have you tried the workaround described here?
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".
@GitMensch good point, thanks! I updated the wiki.