Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python/GDB compatibility issues #1

Closed
fanbin opened this issue Sep 12, 2015 · 21 comments
Closed

Python/GDB compatibility issues #1

fanbin opened this issue Sep 12, 2015 · 21 comments

Comments

@fanbin
Copy link

fanbin commented Sep 12, 2015

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.

@mlncn mlncn mentioned this issue Sep 12, 2015
@mlncn
Copy link

mlncn commented Sep 12, 2015

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

@cyrus-and
Copy link
Owner

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.

@fanbin
Copy link
Author

fanbin commented Sep 12, 2015

@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.

@cyrus-and
Copy link
Owner

@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.

@cyrus-and
Copy link
Owner

cyrus-and commented Sep 13, 2015

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

cyrus-and added a commit that referenced this issue Sep 13, 2015
@cyrus-and cyrus-and changed the title probably need to specify baseline python gdb module version Python/GDB compatibility issues Sep 13, 2015
@fanbin
Copy link
Author

fanbin commented Sep 16, 2015

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

@c02y
Copy link

c02y commented Jan 28, 2016

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?

@cyrus-and
Copy link
Owner

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

@c02y
Copy link

c02y commented Jan 29, 2016

Thank you, it works.

@rofl0r
Copy link

rofl0r commented Feb 9, 2016

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).

@cyrus-and
Copy link
Owner

@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.

@rofl0r
Copy link

rofl0r commented Feb 9, 2016

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

@cyrus-and
Copy link
Owner

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 '$'

@mohit3112
Copy link

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)

@cyrus-and
Copy link
Owner

cyrus-and commented Nov 29, 2016

@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?

@mohit3112
Copy link

@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)

@cyrus-and
Copy link
Owner

@mohit3112 let's continue the discussion in #50

@GitMensch
Copy link

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'
ââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
>>>

@cyrus-and
Copy link
Owner

@GitMensch have you tried the workaround described here?

@GitMensch
Copy link

GitMensch commented May 18, 2021

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".

@cyrus-and
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants