This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: patch to top.c to prevent gdb from being thrown into the background


J. Johnston writes:
 > The attached patch fixes a current problem with gdb regarding attaching to a 
 > background process in the same terminal window the background process was 
 > started in.
 > 
 > In the particular example, the attach started issuing messages regarding the 
 > symbols loaded from shared libraries.  Because the number of shared libraries 
 > was quite large in this case, a page break occurred which caused readline() to 
 > be called.  The first readline() made a call to tcsetattr() which pushed gdb 
 > into the background under Linux.
 > 

Is something liek this happening? I am not sure I fully understand what's going on:

If tcsetattr() is called from a process which is a member of a
background process group on a fildes associated with its controlling
terminal:

    * If the calling process is blocking or ignoring SIGTTOU signals,
      the operation completes normally and no signal is sent.
    * Otherwise, a SIGTTOU signal shall be sent to the process group.

(this is from the posix specs)

 > There is a separate problem regarding whether the output of the shared library 
 > loads should be unfiltered in which case the problem would not have occurred, 
 > but I am creating a separate thread for that issue.
 > 
 > The fix is simply to call terminal_ours() before calling readline() in 
 > gdb_readline_wrapper().  I have tested on i686 linux.
 > 


How about adding something to the attach command itself instead?

Usually the sequence of events (w/o attaching) is 
1. read the symbols (in which case the termnal is ours)
then 
2. start the inferior (in which case the terminal is not ours)

in the attach command, the sequence is reversed and the reading of
symbols is done after the inferior is waited for (during the wait, as
in 2 above, the terminal is not ours). The terminal remains the
inferiors also when the symbol reading is done.

So something like this? (tested by using 'set height 1', but not really well tested)

--- infcmd.c    24 Oct 2003 17:37:03 -0000      1.98
+++ infcmd.c    29 Oct 2003 22:09:06 -0000
@@ -1845,6 +1845,8 @@ attach_command (char *args, int from_tty
    * If no exec file is yet known, try to determine it from the
    * process itself.
    */
+
+  target_terminal_ours();
   exec_file = (char *) get_exec_file (0);
   if (!exec_file)
     {
@@ -1866,13 +1868,14 @@ attach_command (char *args, int from_tty
          symbol_file_add_main (full_exec_path, from_tty);
        }
     }
-
 #ifdef SOLIB_ADD
   /* Add shared library symbols from the newly attached process, if any.  */
   SOLIB_ADD ((char *) 0, from_tty, &current_target, auto_solib_add);
   re_enable_breakpoints_in_shlibs ();
 #endif
  
+  target_terminal_inferior();
+
   /* Take any necessary post-attaching actions for this platform.
    */
   target_post_attach (PIDGET (inferior_ptid));


I am not totally sure about the position of the target_terminal_inferior.

elena


 > Ok to commit?
 > 
 > 2003-10-21  Jeff Johnston  <jjohnstn@redhat.com>
 > 
 > 	* top.c (gdb_readline_wrapper): Ensure terminal is gdb's before calling
 > 	readline.
 > Index: top.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/top.c,v
 > retrieving revision 1.73.4.2
 > diff -u -p -r1.73.4.2 top.c
 > --- top.c	22 Sep 2003 17:50:32 -0000	1.73.4.2
 > +++ top.c	21 Oct 2003 21:19:10 -0000
 > @@ -969,6 +969,13 @@ gdb_readline_wrapper (char *prompt)
 >        after_char_processing_hook = NULL;
 >      }
 >  
 > +  /* Before calling readline, ensure we have the terminal.  If we don't
 > +     have the terminal and call readline, we risk the possibility of
 > +     gdb being thrown into the background.  This problem occurs when
 > +     we attach to a background process on the same terminal the background
 > +     process was started from and then perform some action which requires
 > +     a page break prompt.  */
 > +  terminal_ours ();
 >    return readline (prompt);
 >  }
 >  


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]