Mail Archives: djgpp-workers/2000/12/31/02:26:30
> 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 -