Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #5613 > unrolled thread

Re: Python enabled gdb on Windows and relocation

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python enabled gdb on Windows and relocation Doug Evans <dje@google.com> - 2011-05-17 13:52 -0700

#5613 — Re: Python enabled gdb on Windows and relocation

On Sun, May 15, 2011 at 9:11 AM, Ruben Van Boxem
<vanboxem.ruben@gmail.com> wrote:
> I am sorry for the repeated messages that no one cares about, but I
> may have discovered GDB in its current form already allows what I
> want: I tried to figure out what exact paths the snake in gdb was
> using to search for its modules, and came up with this:
> (gdb) python import sys
> (gdb) python print sys.path
> ['m:\\development\\mingw64\\share\\gdb/python',
> 'M:\\Development\\mingw64\\bin\\python27.zip',
> 'M:\\Development\\mingw64\\bin\\DLLs',
> 'M:\\Development\\mingw64\\bin\\lib',
> 'M:\\Development\\mingw64\\bin\\lib\\plat-win',
> 'M:\\Development\\mingw64\\bin\\lib\\lib-tk',
> 'M:\\Development\\mingw64\\bin',
> 'M:\\Development\\mingw64\\bin\\lib\\site-packages']
>
> This means that every python command within gdb searches
> <sysroot>/share/gdb/python FIRST (even before an environment's
> PYTHONPATH), alleviating any concerns or problems I or anyone would
> have with another python installation, as this apparently built-in
> path comes up first. All I, or anyone interested in doing this kind of
> thing, have to do is copy all the python scripts from the Windows
> installation's Lib directory to the <sysroot>/share/gdb/python
> directory.
>
> I don't know where this path comes from, but it is quite handy, and
> makes this whole discussion  moot for Python people. Only "issue" that
> I'll have to work around is the --with-python-includes and
> --with-python-libs that are missing, using either manual
> CFLAGS/LDFLAGS or a variant of your script.

IMO *if* gdb wanted to support people adding files to *its*
<sysroot>/share/gdb directory, more thought is needed - e.g. maybe
document a "site" directory for such files.  Dunno.  IMO we certainly
don't want to formally allow folks to willy-nilly put anything there -
no guarantees a future release might add something that collides with
something the user put there.
If and until then, you're probably pretty safe if you put everything
in a subdirectory with a unique enough name, if you really wanted to
go this route.

Btw, there is the system.gdbinit file which sites *are* free to customize.

E.g., configure --with-system-gdbinit=<sysroot>/share/gdb/system.gdbinit.

You can put whatever you want in that file.
E.g., you could add a directory to python's sys.path.

[Technically speaking, the path <sysroot>/share/gdb/system.gdbinit
goes against what I just said, but IMO this name is safe.]

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web