[Python] Input from user from extended breakpoint `stop' function

[Python] Input from user from extended breakpoint `stop' function

[Kevin Pouget]

Hello,

is there any function provided by GDB to read from the terminal ?
(I still don't know much about Python)

I'm facing a problem when I was to ask a question the user from an
extended breakpoint `stop' function: try

class MyBreakpoint (gdb.Breakpoint):
	def stop (self):
		bug = raw_input("Input ?")
		print "--> ", bug
		return True
MyBreakpoint(spec="main")


and you will see this output:

> (gdb) source sigttin.py
> Breakpoint 1 at 0x400579
> (gdb) r
> Starting program: /home/kevin/a.out
> Input ?
> [1]+  Stopped                 gdb-git a.out
> kevin@kevin:~$ fg
> gdb-git a.out
> hello
> -->  hello
> Breakpoint 1, 0x0000000000400579 in main ()

because GDB receives a SIGTTIN ("SIGTTIN is the signal sent to a
process when it attempts to read from the tty while in the
background." says wikipedia), which somehow makes sense.

Any solution, or shall I send a bug report?


cordially,

Kevin

Re: [Python] Input from user from extended breakpoint `stop' function

[Phil Muldoon]

Kevin Pouget <kevin.pouget@gmail.com> writes:

> Hello,
>
> is there any function provided by GDB to read from the terminal ?
> (I still don't know much about Python)

Nope, but in the context of this bug there might need to be.  GDB does a
few things with stdout/tty.

> I'm facing a problem when I was to ask a question the user from an
> extended breakpoint `stop' function: try
>
> class MyBreakpoint (gdb.Breakpoint):
> 	def stop (self):
> 		bug = raw_input("Input ?")
> 		print "--> ", bug
> 		return True
> MyBreakpoint(spec="main")
>
>
> and you will see this output:
>
>> (gdb) source sigttin.py
>> Breakpoint 1 at 0x400579
>> (gdb) r
>> Starting program: /home/kevin/a.out
>> Input ?
>> [1]+  Stopped                 gdb-git a.out
>> kevin@kevin:~$ fg
>> gdb-git a.out
>> hello
>> -->  hello
>> Breakpoint 1, 0x0000000000400579 in main ()
>
> because GDB receives a SIGTTIN ("SIGTTIN is the signal sent to a
> process when it attempts to read from the tty while in the
> background." says wikipedia), which somehow makes sense.

I'm not sure what is going on here.  It seems GDB is not acting
correctly with the SIGTTIN.  I really do not know this area of GDB at
all.


> Any solution, or shall I send a bug report?

Bug report please.

Cheers,

Phil

Re: [Python] Input from user from extended breakpoint `stop' function

[Andreas Schwab]

Phil Muldoon <pmuldoon@redhat.com> writes:

> I'm not sure what is going on here.  It seems GDB is not acting
> correctly with the SIGTTIN.  I really do not know this area of GDB at
> all.

The terminal still belongs to the inferior.  Before gdb is doing any
input it must call terminal_ours.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Python] Input from user from extended breakpoint `stop' function

[Phil Muldoon]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Phil Muldoon <pmuldoon@redhat.com> writes:
>
>> I'm not sure what is going on here.  It seems GDB is not acting
>> correctly with the SIGTTIN.  I really do not know this area of GDB at
>> all.
>
> The terminal still belongs to the inferior.  Before gdb is doing any
> input it must call terminal_ours.

Thanks, that is good info. I did not know that.  I wonder if we should
call that before handing over control to the python executed script in
the breakpoint "stop" callback? Or maybe provide a Python API call to
turn control of the TTY to GDB and likewise to the inferior.

Any opinions on this would be great. What do you (all) think?

Cheers

Phil

Re: [Python] Input from user from extended breakpoint `stop' function

[Kevin Pouget]

>> Any solution, or shall I send a bug report?
>  Bug report please.
http://sourceware.org/bugzilla/show_bug.cgi?id=12686 (what does PR mean ?)


>> The terminal still belongs to the inferior.  Before gdb is doing any
>> input it must call terminal_ours.
that's interesting, but why `print' functions work correctly, without
sending any SIGTTOU


> Thanks, that is good info. I did not know that.  I wonder if we should
> call that before handing over control to the python executed script in
> the breakpoint "stop" callback? Or maybe provide a Python API call to
> turn control of the TTY to GDB and likewise to the inferior.
>
> Any opinions on this would be great. What do you (all) think?

I would prefer a python-transparent handling, ie `terminal_ours'
called before giving the hand to the Python callback, to hide GDB's
complexity from the script interface (I guess there won't be so many
situations where this case occurs?).
However if `terminal_ours' is very costly (in comparison to the
breakpoint itself), it might not be very wise ...


Cordially,

Kevin

Re: [Python] Input from user from extended breakpoint `stop' function

[Andreas Schwab]

Kevin Pouget <kevin.pouget@gmail.com> writes:

>>> Any solution, or shall I send a bug report?
>>  Bug report please.
> http://sourceware.org/bugzilla/show_bug.cgi?id=12686 (what does PR mean ?)
>
>
>>> The terminal still belongs to the inferior.  Before gdb is doing any
>>> input it must call terminal_ours.
> that's interesting, but why `print' functions work correctly, without
> sending any SIGTTOU

Try stty tostop.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Python] Input from user from extended breakpoint `stop' function

[Tom Tromey]

>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:

Phil> I wonder if we should call that before handing over control to the
Phil> python executed script in the breakpoint "stop" callback?

I don't think so.

Phil> Or maybe provide a Python API call to turn control of the TTY to
Phil> GDB and likewise to the inferior.

This would be ok with me.

Tom

Re: [Python] Input from user from extended breakpoint `stop' function

[Kevin Pouget]

>> that's interesting, but why `print' functions work correctly, without
>> sending any SIGTTOU
>
> Try stty tostop.

indeed !
what do consider as the default/good behavior? I mean, it is okay for
GDB to 'ignore' SIGTTOU, or shall I report such situations as bugs ?