>>>>> OKUJI Yoshinori writes:
OY> The safest way is to use the `clone' system call and set the
OY> stack pointer of the new process to the pointer you want to
OY> specify.
OY> In general, it's very dangerous to change the stack pointer of a
OY> process after the process starts up, because you cannot use any
OY> variable on realstack when the stack points to
OY> simstack. Therefore, you had better create a new process.
I realize this, and have checked to make sure that asmstub.c is
entirely self-contained (i.e. the critical section in grub_stage2
doesn't contain any references to the old stack). What I am having
problems with is getting GCC not to clobber the stack with its
optimizations.
I suppose I could do it all from an assembler routine, but I was
hoping for something easier. ;)
>> My reason is that I want grub_scratch_mem to be a memory image of
>> the i386 machine at bootup. That way, I can check for buffer and
>> stack overruns the same as Electric Fence.
OY> I think your idea is very good, so I'd like you not to change
OY> the meanings of the variables as well as the memory
OY> arrangement. For example, you should not use `geometry' to store
OY> a pointer to FILE.
Yes, I agree. The FILE hack is only temporary... it won't be in 0.6.
OY> By the way, if you want to simulate grub on Unix perfectly, i386
OY> simulator is greater than the glue code. i386 simulator is
OY> described in the task list of GNU, but I don't know if someone is
OY> already working on it. Do you know?
I don't know, either.
I have thought about it, though... and I will be taking long-term
steps that will make it possible to fork GRUB into a separate,
generic, i386 simulator, rather than focusing just on bootloading.
Thanks for your notes,
--
Gordon Matzigkeit <[EMAIL PROTECTED]> //\ I'm a FIG (http://www.fig.org/)
Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)
