delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/12/31/02:26:30

Date: Sun, 31 Dec 2000 09:24:18 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
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: <Pine DOT SUN DOT 3 DOT 91 DOT 1001225105646 DOT 18547E-100000 AT is> <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

> Date: Thu, 28 Dec 2000 18:14:31 +0000
> From: Richard Dawe <richdawe AT bigfoot DOT com>
> 
> > > 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...

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019