This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Make the "python" command resemble the standard Python interpreter
Hi,
On Jan 11, 2012, at 4:30 PM, Tom Tromey wrote:
>>>>>> "Yit" == Khoo Yit Phang <khooyp@cs.umd.edu> writes:
>
> Yit> Attached is a new patch that uses another way to disable the readline
> Yit> module, which works with pdb.set_trace(). However, readline support
> Yit> still doesn't work with pdb. The reason is because pdb uses raw_input,
> Yit> which in turn uses sys.stdin/sys.stdout to determine whether to use
> Yit> readline, but GDB replaces sys.stdin/sys.stdout with it's own
> Yit> file-like objects that isn't recognized as a tty by Python.
>
> This sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12150
> Maybe we should try to fix that instead?
Yes, it's related, if I understand correctly, sys.stdout/sys.stderr are overridden the way they are so that GDB can capture/filter the output. Another solution, besides overriding raw_input/input, would be to point sys.stdout/sys.stderr to a PTY, though I'm not sure what the trade-offs are.
> Yit> Making Python's readline module work under GDB is not possible, since
> Yit> it re-initializes libreadline and generally assumes that libreadline
> Yit> is completely under Python's control (and libreadline itself has no
> Yit> support for nesting/reentrancy).
>
> The initialization shouldn't be a problem.
>
> Calling rl_initialize multiple times is ok -- readline() itself calls
> it.
However, other configuration cannot be set repeatedly, e.g., rl_readline_name, rl_completion_*, various rl_*_hook, keybindings, and so on.
> I don't know about the reentrancy though. Also, IIRC, gdb uses the
> unusual async interface. Maybe that raises some issues.
That may explain another issue I've seen where inputs are delayed by one keystroke.
Yit
January 11, 2011