It's in Tools/gdb/libpython.py in Python 2.7+.
It appears Python port is abandoned.
Over to maintainer.
Note, this is a volunteer project, if you really want something, might be a good idea to provide a patch.
I'm a volunteer too, Mathieu.
E.g., Index: Makefile =================================================================== --- Makefile (revision 438066) +++ Makefile (working copy) @@ -125,6 +125,8 @@ post-install: for i in ${STAGEDIR}${PREFIX}/lib/python2.7/lib-dynload/*.so; do \ ${STRIP_CMD} $$i; done # Strip shared extensions + install -m444 ${WRKSRC}/Tools/gdb/libpython.py \ + ${STAGEDIR}${PREFIX}/debug/${LOCALBASE}/lib/libpython2.7.so.1.0.debug-gdb.py .include <bsd.port.pre.mk> Index: pkg-plist =================================================================== --- pkg-plist (revision 438066) +++ pkg-plist (working copy) @@ -4545,3 +4545,4 @@ lib/python2.7/zipfile.pyo libdata/pkgconfig/python-2.7.pc man/man1/python2.7.1.gz +debug/${LOCALBASE}/lib/libpython2.7.so.1.0.debug-gdb.py
The path "${LOCALBASE}/lib/libpython2.7.so.1-gdb.py" may also work. That's what we use at $DAYJOB, although we may modify the default GDB search path to make that work.
@Conrad Could you include your patch as an attachment please, or alternatively (preferred), open a Phabricator review (adding the review URl to the URl field in bugzilla). Can you also confirm: - That the patch passes QA (poudriere) - To what extent this change should be made across all Python port versions. Ideally, include the changes for the other port versions in the patch/review as well - Whether this change (the addition of the file) should only be made when the DEBUG port option is on, or unconditionally, with rationale if possible.
(In reply to Kubilay Kocak from comment #7) > Could you include your patch as an attachment please, or alternatively (preferred), open a Phabricator review (adding the review URl to the URl field in bugzilla). Done. > Can you also confirm: > > - That the patch passes QA (poudriere) Do we have any cluster machines that can be used for poudriere? I'm moving in two days and my FreeBSD machines are packed. > - To what extent this change should be made across all Python port versions. Ideally, include the changes for the other port versions in the patch/review as well It should be done for all Python versions (and the patch does). > - Whether this change (the addition of the file) should only be made when the DEBUG port option is on, or unconditionally, with rationale if possible. I don't see any reason to limit it to DEBUG.
The patch is here if anyone will commit it: https://reviews.freebsd.org/D10398 Unfortunately, no one from python@ will review it and I am not allowed to commit it.
@Conrad, during QA (with DEVELOPER=yes in /etc/make.conf), I observe the following: ====> Running Q/A tests (stage-qa) readelf: Not an ELF file. Warning: /wrkdirs/usr/ports/lang/python27/work/stage/usr/local/lib/libpython2.7.so.1-gdb.py doesn't have a SONAME. Warning: pkg(8) will not register it as being provided by the port. Warning: If another port depend on it, pkg will not be able to know where it comes from. Warning: It is directly in /usr/local/lib, it is probably used by other ports. I'm not sure what this might mean for desired functionality out of the box for the port or binary package. This may not be an issue if no other ports depend (LIB_DEPENDS) on it. Have you tested whether GDB works as expected with libpython2.7.so.1-gdb.py in that location and confirmed it works without additional intervention once installed? CC'ing Baptiste who might be able to provide some guidance.
It just occurred to me that this may just be a *.so file name matching thing. If so, is it possible (from a 'it works out of the box') point of view to either rename the file and/or put it in a still-suitable location not inside LOCALBASE/lib?
(In reply to Kubilay Kocak from comment #10) > @Conrad, during QA (with DEVELOPER=yes in /etc/make.conf), I observe the following: > > ====> Running Q/A tests (stage-qa) > readelf: Not an ELF file. > Warning: /wrkdirs/usr/ports/lang/python27/work/stage/usr/local/lib/libpython2.7.so.1-gdb.py > doesn't have a SONAME. > Warning: pkg(8) will not register it as being provided by the port. > Warning: If another port depend on it, pkg will not be able to know where it comes from. > Warning: It is directly in /usr/local/lib, it is probably used by other ports. This is a spurious warning -- it isn't a shared object and obviously nothing can use it like one. > I'm not sure what this might mean for desired functionality out of the box for the port > or binary package. This may not be an issue if no other ports depend (LIB_DEPENDS) on it. I don't think it's an issue -- it's not a shared object, nothing can LIB_DEPENDS on it. > Have you tested whether GDB works as expected with libpython2.7.so.1-gdb.py in that > location and confirmed it works without additional intervention once installed? Yep, see comment #6. We use it pretty frequently at work. # ls /usr/local/lib/libpython2.7.so.1* /usr/local/lib/libpython2.7.so.1 /usr/local/lib/libpython2.7.so.1-gdb.py # echo -e "import os\nos.abort()" > a.py # gdb771 --args python a.py ... (gdb) r ... Program received signal SIGABRT, Aborted. [Switching to Thread 8006c1400 (LWP 100708)] 0x000000080129d84a in thr_kill () from /lib/libc.so.7 (gdb) py-bt Traceback (most recent call first): File "a.py", line 2, in <module> os.abort() (gdb) py-list 1 import os >2 os.abort() (In reply to Kubilay Kocak from comment #11) > It just occurred to me that this may just be a *.so file name matching thing. Yep. > If so, is it possible (from a 'it works out of the box') point of view to either rename > the file and/or put it in a still-suitable location not inside LOCALBASE/lib? The name can't be changed, I think. There are a few suitable locations. Fedora uses a location associated with the separated shared object debuginfo, which ports doesn't support: /usr/lib/debug/usr/lib64/libpython2.7.so.1.0.debug-gdb.py Note that this portion ^^^^^^^^^^^^^^^^^^^^^^^^^ has to match some file GDB is loading already. I'm not sure what search paths GDB has by default. In the differential review, someone mentioned: /usr/local/share/gdb/auto-load/usr/local/lib/libglib-2.0.so.0.5000.2-gdb.py This is discussed a little bit more in the first few comments of the review.
A commit references this bug: Author: koobs Date: Tue Jun 6 12:56:49 UTC 2017 New revision: 442759 URL: https://svnweb.freebsd.org/changeset/ports/442759 Log: lang/python{27,33,34,35,36}: Install GDB debugging script Users with a GDB that supports [1] Python extensions will automatically load the extra debugging extensions when debugging programs that are linked with libpythonX.Y.so.foo. This enables extensions like 'py-bt' and 'py-frame' as described in the Fedora Wiki Article: Easier Python Debugging [2], which can be useful for debugging Python program state from crashes in C extensions, for example. [1] PYTHON option enabled in devel/gdb [2] https://fedoraproject.org/wiki/Features/EasierPythonDebugging PR: 203021 Submitted by: cem Reviewed by: mat, koobs (python) Approved by: koobs (python) Differential Revision: D10398 Changes: head/lang/python27/Makefile head/lang/python27/pkg-plist head/lang/python33/Makefile head/lang/python33/pkg-plist head/lang/python34/Makefile head/lang/python34/pkg-plist head/lang/python35/Makefile head/lang/python35/pkg-plist head/lang/python36/Makefile head/lang/python36/pkg-plist
Thank you for the feature addition to Python/GDB Conrad, apologies it took so long to get it in.
Thanks for getting it in, Kubilay.
(In reply to Conrad Meyer from comment #15) My pleasure, you're welcome
I tried this after rebuilding lang/python36 and devel/gdb with the following options: _OPTIONS_READ=python36-3.6.1_1 _FILE_COMPLETE_OPTIONS_LIST=DEBUG IPV6 LIBFFI NLS PYMALLOC THREADS FNV SIPHASH OPTIONS_FILE_UNSET+=DEBUG OPTIONS_FILE_UNSET+=IPV6 OPTIONS_FILE_SET+=LIBFFI OPTIONS_FILE_SET+=NLS OPTIONS_FILE_SET+=PYMALLOC OPTIONS_FILE_SET+=THREADS OPTIONS_FILE_UNSET+=FNV OPTIONS_FILE_SET+=SIPHASH and: _OPTIONS_READ=gdb-7.12.1_1 _FILE_COMPLETE_OPTIONS_LIST=DEBUG GDB_LINK GUILE KGDB PYTHON TUI BUNDLED_READLINE PORT_READLINE OPTIONS_FILE_UNSET+=DEBUG OPTIONS_FILE_SET+=GDB_LINK OPTIONS_FILE_UNSET+=GUILE OPTIONS_FILE_SET+=KGDB OPTIONS_FILE_SET+=PYTHON OPTIONS_FILE_SET+=TUI OPTIONS_FILE_UNSET+=BUNDLED_READLINE OPTIONS_FILE_SET+=PORT_READLINE Attempting `py-bt' gave me the following error: (gdb) py-bt Python Exception <type 'exceptions.ValueError'> Variable 'func_obj' not found.: Error occurred in Python command: Variable 'func_obj' not found. I then found this Python-ticket: https://bugs.python.org/issue30345 and tried the patch referenced there (https://github.com/python/cpython/commit/d05f7fdf6cf77724bd3064fb5a0846ef5cfe0c88). Unfortunately, that didn't help: (gdb) py-frame Undefined command: "py-frame". Try "help". (gdb) py-bt Python Exception <type 'exceptions.ValueError'> Variable 'func_obj' not found.: Error occurred in Python command: Variable 'func_obj' not found. Looks like something is still missing -- at least, in the case of 3.6.
Thank you for the report Mikhail. In future for these kinds of issues, please create a new issue referencing (see also) the original. That is to say: issues landing a feature, and bugs/issues identified with that feature after release should be separate (but linked/referenced). This ensures titles, investigations and conversation, and assignees can remain distinct and accurate.
Request feedback from Conrad
I also think this bug should be followed up in a separate issue.