Date: Sun, 31 Dec 2000 09:24:18 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: rich AT phekda DOT freeserve DOT co DOT uk Message-Id: <3405-Sun31Dec2000092417+0200-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6 CC: djgpp-workers AT delorie DOT com In-reply-to: <3A4B8307.F4EF8D0@bigfoot.com> (message from Richard Dawe on Thu, 28 Dec 2000 18:14:31 +0000) Subject: Re: An implementation of /dev/zero for DJGPP References: <3A489766 DOT 349B3C71 AT bigfoot DOT com> <9003-Tue26Dec2000184539+0200-eliz AT is DOT elta DOT co DOT il> <3A4B8307 DOT F4EF8D0 AT bigfoot DOT com> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > Date: Thu, 28 Dec 2000 18:14:31 +0000 > From: Richard Dawe > > > > Does the debug FSEXT work like this? Or does it leave the fd's data > > > pointer alone? > [snip] > > Btw, since the debug support hooks the handle at startup (its > > initialization routine is declared "__attribute__((constructor))"), it > > is actually the /dev/zero FSEXT which will cause trouble, unless you > > add special code to chain to the previous hook. > > Would the /dev/zero hook actually get called, when the debug FSEXT is > present? Surely the debug FSEXT is the first FSEXT, because of the > constructor. So, if a program using the debug FSEXT tries to open e.g. > /dev/zero, it will fail, because the debug FSEXT "knows" nothing about > /dev/zero. The debug FSEXT records the open files, but then chains to the original handler. Here's the relevant fragment of dbg_fsext: case __FSEXT_open: filename = va_arg(_args,const char *); oflag = va_arg(_args,int); in_dbg_fsext++; retval = _open(filename,oflag); #ifdef DEBUG_DBGCOM_FILES fprintf(stderr,"_open(%s) => %d\n",filename,retval); #endif in_dbg_fsext--; if (retval != -1) { handles[retval] = retval; __FSEXT_set_function(retval,dbg_fsext); } break; See that in_dbg_fsext++/in_dbg_fsext-- pair around the call to _open? The top of dbg_fsext has this snippet: /* We are called from this function */ if (in_dbg_fsext) return 0; So, the first time someone opens /dev/zero, dbg_fsext will be called and will register the fact that it was open. The call to _open issued from dbg_fsext will then activate the /dev/zero FSEXT. When the call to _open returns, dbg_fsext overwrites the value stored by __FSEXT_set_function by its own address. From that moment on, the /dev/zero fsext will no longer be called when any operation on that handle is done. > I think I am missing something here - the debug FSEXT is only used within > the debugger, right? Yes. > Its purpose seems to be to clean up any handles the child program > has created. Yes, it needs to close all the handles open by the debuggee, in order to be able to restart the debuggee without losing handles. > So, I think the /dev/zero cannot cause trouble with the debug FSEXT. (This > is with /dev/zero being installed using __install_dev_zero(), as discussed > previously.) If the debugger itself calls __install_dev_zero, its /dev/zero emulation will not work. I'm not sure this is a grave limitation, but it at least should be documented somewhere. > "The value returned may be less than nbyte if the number of bytes left in > the file is less than nbyte, if the read() request was interrupted by a > signal, or if the file is a pipe or FIFO or special file and has fewer > than nbyte bytes immediately available for reading. For example, a read() > from a file associated with a terminal may return one typed line of data." > > Does /dev/zero fit into the "special file" category? I don't know. I simply thought that we shouldn't create an impression there was a problem where none happened. But the point might be moot anyway, since, as DJ pointed out, there are not many DJGPP systems which have more than 2GB of memory...