Loading ...
Sorry, an error occurred while loading the content.

Re: VimGDB and ifndef HAVE_SELECT

Expand Messages
  • Malte Neumann
    Hi Xavier, soory for this very long time of silence. I was really busy at work for some time, then on holiday,.... But now after using this more or less
    Message 1 of 19 , Aug 24, 2004
    • 0 Attachment
      Hi Xavier,

      soory for this very long time of silence. I was really busy at work for some
      time, then on holiday,....

      But now after using this more or less working VimGDB for some time I believe
      it would be nice to have the completely working thing.


      To keep things clear, I started again from the pure Vim 6.2 code and the
      patches Version 6.

      This original version crashes when opening a file with ':e' (both vim and
      gvim).


      The only change I made to the code is adding the line 3522 as described
      below.


      On Wed, May 26, 2004 at 09:23:59AM -0400, Xavier de Gaye wrote:
      >
      > On 5/13/2004 Malte Neumann wrote:
      > On Thu, May 13, 2004 at 09:48:01AM -0400, Xavier de Gaye wrote:
      > > > a) In mch_call_shell() after line 3521 (so it's more clear, I am
      > > > using line numbers from the original Vim62 os_unix.c file, not the
      > > > patched one):
      > > >
      > > > _exit(EXEC_FAILED); /* exec failed, return failure code */
      > > > }
      > > > else /* parent */
      > > > {
      > > > /*
      > > > * While child is running, ignore terminating signals.
      > > > */
      > > > 3521 --> catch_signals(SIG_IGN, SIG_ERR);
      > > >
      > > > add at line 3522 after catch_signals():
      > > >
      > > > 3522 --> signal(SIGCHLD, SIG_IGN);

      This version now behaves much better:

      With gvim it is now possible to open files, start gdb, and step through the
      code. It is even possible to quit gdb and restart it afterwards.

      vim does not open any files, it just hangs after displaying the line:
      "main.c" 162L, 5409C


      > After setting SIGCHLD to SIG_IGN at line 3522 above, vim (not gvim)
      > executes _ONLY_ the following lines before SIGCHLD is set
      > back again to gdb_catch_sigchld() in set_signals():
      >
      > while (wait_pid != pid)
      > {
      > wait_pid = wait(&status);
      > if (wait_pid <= 0 && errno == ECHILD)
      > break;
      > }
      >
      > /*
      > * Set to raw mode right now, otherwise a CTRL-C after
      > * catch_signals() will kill Vim.
      > */
      > if (tmode == TMODE_RAW)
      > settmode(TMODE_RAW);
      > did_settmode = TRUE;
      > --> set_signals(); <-- SIGCHLD back to gdb_catch_sigchld()
      >
      >
      > What do the man pages say about the argument to wait(), is it a
      > pointer to an int ?

      'man 2 wait' gives the following:

      wait(2)

      NAME
      wait, waitpid - wait for child process to stop or terminate

      SYNOPSIS
      #include <sys/types.h> OH
      #include <sys/wait.h>

      pid_t wait(int *stat_loc);

      pid_t waitpid(pid_t pid, int *stat_loc, int options);

      So, it is an pointer to an int.


      > Does gcc give any warning on these lines when compiling os_unix.c ?

      The only warning I get when compiling os_unix.c is the following:

      os_unix.c: In function `RealWaitForChar':
      os_unix.c:4273: warning: passing arg 1 of `poll' from incompatible pointer
      type

      where line 4273 is the following:
      ret = poll(&fds, nfd, (int)msec);


      > With the fix in line 3522 above, can you have two GDB consecutive
      > sessions within the same VimGDB session ?
      > use the GDB "quit" command, to end the current GDB session: this
      > will test VimGDB's handling of waitpid().

      Yes, see above.

      > Ah, and also another check we have not made yet:
      > remove line 3522 above
      > replace gdb_sigchld() contents in gdb.c with just one
      > statement:
      > return FALSE;
      > does it crash ?

      vim crashes in the same way as the original does.

      gvim does not crash, the file is opened, but the <F7> to map the keys does
      not work.


      > > [...]
      > > Ok. I didn't try <CTRL-Z>. But it works, when in the input-window, <CTRL-Z>
      > > interrupts the gdb command.
      > > [...]
      >
      > You can also type <CTRL-Z> from anywhere, not only the input-window, when
      > gdb_mappings.vim has been sourced and mappings toggled with <F7>.
      >
      >
      >
      > > [...]
      > > > e) Does the input-line window works: to test that, run twice the GDB
      > > > "file" command on the same file, you get:
      > > >
      > > > Load new symbol table from "foobar"? (y or n)
      > > >
      > > > and the input-line window _MUST_ pop up.
      > >
      > > The input-line window DOES pop up, but when entering y and <ENTER> the
      > > window closes and nothing happens. After that gdb is again busy.
      > >
      > > interrupting gdb after that, the symbols are loaded.
      >
      >
      > Do you have 'y' echoed after the prompt (y or n) ?
      > (gdb) file foobar
      > Load new symbol table from "foobar"? (y or n) y
      > Reading symbols from foobar...done.
      > (gdb)

      No, the 'y' is not echod.

      The output looks like this:

      (gdb) Load new symbol table from "foobar.debg"? (y or n) Reading symbols from ~/wdir/ccarat_fluidfast/cca_11_seq.debg...done.
      (gdb)

      Everything in one line, the part 'Reading symbols...' appears after
      interrupting gdb.

      > Another test is to "define" a sequence of commands, like this:
      >
      > (gdb) define foobar
      > Type commands for definition of "foobar".
      > End with a line saying just "end".
      > >print anything
      > >end
      > (gdb)
      >
      > Does this work ?

      This DOES work, but the commands 'print anything' and 'end' are not echoed in
      the gdb-output window. Just the second prompt appears after entering 'print
      anything':

      (gdb) Type commands for definition of "barfoo".
      End with a line saying just "end".
      >>(gdb)


      > Try please, to prevent commands from being discarded and remove
      > "GDB busy: command discarded, please retry" messages:
      > in gdb.c: in gdb_docmd() comment out 5 lines:
      >
      > /* accept one cmd at a time, allow intr */
      > if (cmd != NULL && *cmd != NUL && *(cmd + STRLEN(cmd) - 1) == KEY_INTERUPT)
      > this->oob.state |= OS_INTR;
      > /* COMMENT OUT THESE 5 LINES
      > * else if (this->oob.state & OS_CMD)
      > * {
      > * give_warning("GDB busy: command discarded, please retry", TRUE);
      > * return;
      > * }
      > * END COMMENT OUT THESE 5 LINES */
      > else
      > this->oob.idx = -1; /* needed when last oob was aborted with OS_QUITs */
      > this->oob.state |= OS_CMD;
      >
      > Does this change anything in the previous tests ?

      No, it does change anything in the behaviour of reloading the symbols or
      defining a sequence of commands.


      Malte


      --
      Malte Neumann
      Institute of Structural Mechanics, University of Stuttgart, Germany
      http://www.uni-stuttgart.de/ibs/members/neumann/
    Your message has been successfully submitted and would be delivered to recipients shortly.