Date: Mon, 31 Aug 1998 12:03:37 +0300 (IDT) From: Eli Zaretskii To: Ignacio =?iso-8859-1?Q?Garc=EDa?= =?iso-8859-1?Q?_P=E9rez?= cc: djgpp AT delorie DOT com Subject: Re: HELP!... execute CODE in DATA segment seems not work In-Reply-To: <3.0.5.32.19980830222809.008647c0@MERCURIO> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 30 Aug 1998, Ignacio =?iso-8859-1?Q?Garc=EDa?= =?iso-8859-1?Q?_P=E9rez?= wrote: > Notice that when _my_ds() is called in the main program, sure I'll get the > DJGPP correct DS selector, and then, I embed it into a constant in the code. The selector is correct, but there are periods in your program's life (see below) when DS is intentionally invalidated. If the timer tick happens during these periods, your program will crash. > This should make the interrupt procedure load the right DS selector at any > time ***unless*** the DJGPP selector varies along the program execution. Is > this possible ?... Yes, it is possible: that's how signals work in DJGPP. When you press Ctrl-C (which is supposed to generate the SIGINT signal), that keypress is caught by the keyboard handler installed by the DJGPP startup code. The handler processes Ctrl-C by making the DS limit be 4K. Since all data in your program lives above the first 4K (that's how things are set up at startup), the first time your program touches any of its data, a CPU exception is generated, because protected mode doesn't allow accesses to data beyond the DS limit. This exception is caught by the DJGPP exception handler, which sees that the exception was generated on behalf of a Ctrl-C, restores the DS limit to its normal value, then calls "raise(SIGINT);". The reason for this complexity is that you could press Ctrl-C while the CPU was in real mode, like when your program calls DOS or BIOS. The signal processing described above makes sure that the signal isn't delivered to your program until the CPU is once again in protected mode and in the normal foreground thread (because only then can it touch any of its data). In particular, since the default action of Ctrl-C is to abort the program, this ensures that the program can *never* be aborted while the CPU is in real mode (the DPMI spec forbids that). The above description doesn't pertain to Ctrl-C alone. All the signals supported in DJGPP that are generated by hardware interrupts, like SIGALRM generated by the timer tick, work that way. The upshot of all that is that if the timer ticks during a period when DS is invalid (because some signal is pending), your handler will crash if it uses DS. Using __djgpp_ds_alias solves this, since that selector has the same base and limit as DS, but is *always* valid. > (and thus necessary to load it every time from __djgpp_ds_alias). No, you just need to patch your wrapper with the alias selector once. There should be no need to reload it.