Re: doscmd broken on current? fixed
On Sun, 7 Nov 1999, John Hay wrote: Ok, with these patches doscmd is working for me again. I can boot dos and run the topspeed C compiler like I used to a few months ago. If nobody has any complaints I'll commit it. I'm just not 100% sure about the patch to doscmd.c and would like if someone with more knowledge about the signal stuff would just look at it. There is just too many signal Index: doscmd.c === RCS file: /home/ncvs/src/usr.bin/doscmd/doscmd.c,v retrieving revision 1.11 diff -u -r1.11 doscmd.c --- doscmd.c 1999/10/13 23:48:35 1.11 +++ doscmd.c 1999/11/07 12:50:06 @@ -258,6 +258,7 @@ sigemptyset(uc.uc_sigmask); sigaltstack(NULL, uc.uc_stack); +uc.uc_mcontext.mc_onstack = uc.uc_stack.ss_flags; if (tmode) tracetrap(REGS); I only know this well enough to use the source quickly. Setting the onstack flag to the stack flags is logically wrong because the onstack flag is a single bit (1 or SS_ONSTACK; see (*)), while the stack flags are some combination of SS_DISABLE and SS_ONSTACK (see sigaltstack(2)). The following would be logically correct: +uc.uc_mcontext.mc_onstack = uc.uc_stack.ss_flags SS_ONSTACK; but since the alternative signal stack is not in use at this point, the rvalue is known to be 0 and the fix can be reduced to: +uc.uc_mcontext.mc_onstack = 0; as in RELENG_3. RELENG_3 also omits the sigaltstack() call (which gives the current (almost known) alt stack settings). I think this is valid because uc_stack and mc_onstack are read-only for signal handlers (any changes to uc_stack will be ignored on sigreturn(), and any changes to mc_onstack will make a mess). When sigreturn() is called with a made-up context as in doscmd:main(), mc_onstack needs to be initialised to avoid making a mess. (*) In RELENG_3, the SS_ONSTACK bit in ss_flags is passed to signal handlers as "sc_onstack = ss_flags SS_ONSTACK" but assumed to be returned via sigreturn() as "sc_onstack 01". Since signal handlers are not expected to modify sc_onstack, this only works if SS_ONSTACK = 1, as it is. In -current, the SS_ONSTACK bit in ss_flags is passed to signal handlers as "mc_onstack = ss_flags SS_ONSTACK ? 1 : 0", so the old handling of the flag in sigreturn() is now logically correct, but this is broken since it changes the semantics for setting mc_onstack. Related problems: The USE_VM86 case in doscmd.c is more broken than in RELENG_3. It is missing sc - uc name changes. Unrelated problems: Your patch for cwd.c helps, but lookup of /dosD/bin/ls.exe is still broken. The path gets converted to //dosd/bin/ls.exe. The // is wrong and the /dosd is broken, since that part of the path is in ffs which is case-sensitive. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: doscmd broken on current?
Is doscmd working for anyone on current? Here I just get: - I have tried it on a single processor and SMP -current and both do the same thing. I had it working a while back, so I think my configuration is ok. Ideas on how to look into this? Start by invoking it with the various debug/trace options. I'd guess that it may be broken by the signal-related changes that were made recently. hehehe It dies at the very first vm86 instruction, so I guess something isn't setup correctly to enter vm86 mode via the sigreturn(): I bet that someone got smart and disallowed PSL_VM in eflags on a return to user-mode. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: doscmd broken on current?
John Hay wrote: Hmmm I see the sigreturn man page hasn't been updated, it still says that sigreturn takes a struct sigcontext * argument, while the signal.h file says it takes ucontext_t *. Sigreturn still takes a struct sigcontext*. It also takes a ucontext_t. I think the header should define sigreturn to take a struct sigcontext*... -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: doscmd broken on current?
Is doscmd working for anyone on current? Here I just get: - I have tried it on a single processor and SMP -current and both do the same thing. I had it working a while back, so I think my configuration is ok. Ideas on how to look into this? Start by invoking it with the various debug/trace options. I'd guess that it may be broken by the signal-related changes that were made recently. hehehe It dies at the very first vm86 instruction, so I guess something isn't setup correctly to enter vm86 mode via the sigreturn(): I bet that someone got smart and disallowed PSL_VM in eflags on a return to user-mode. Nope it wasn't that bad. I'm not sure if this is the correct fix, but with this patch I can boot dos again. Can someone with more knowledge of the signal stuff look and say if this is correct/enough? The redirector don't work though. I just get a "File not Found" error when trying to dir any of the redirected directories. John -- John Hay -- [EMAIL PROTECTED] Index: doscmd.c === RCS file: /home/ncvs/src/usr.bin/doscmd/doscmd.c,v retrieving revision 1.11 diff -u -r1.11 doscmd.c --- doscmd.c1999/10/13 23:48:35 1.11 +++ doscmd.c1999/11/07 12:50:06 @@ -258,6 +258,7 @@ sigemptyset(uc.uc_sigmask); sigaltstack(NULL, uc.uc_stack); +uc.uc_mcontext.mc_onstack = uc.uc_stack.ss_flags; if (tmode) tracetrap(REGS); To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: doscmd broken on current? fixed
Ok, with these patches doscmd is working for me again. I can boot dos and
run the topspeed C compiler like I used to a few months ago.
If nobody has any complaints I'll commit it. I'm just not 100% sure about
the patch to doscmd.c and would like if someone with more knowledge about
the signal stuff would just look at it. There is just too many signal
related functions and structures and it isn't always clear (to me at least)
what should be filled in for whom.
John
--
John Hay -- [EMAIL PROTECTED]
Index: cwd.c
===
RCS file: /home/ncvs/src/usr.bin/doscmd/cwd.c,v
retrieving revision 1.5
diff -u -r1.5 cwd.c
--- cwd.c 1999/10/12 22:20:18 1.5
+++ cwd.c 1999/11/07 18:59:06
@@ -198,7 +198,7 @@
u_char *np;
Path_t *d;
u_char tmppath[1024];
-u_char snewpath = newpath;
+u_char *snewpath = newpath;
if (where[0] != '\0' where[1] == ':') {
drive = drlton(*where);
@@ -253,7 +253,7 @@
} else {
if (np[-1] != '\\')
*np++ = '\\';
- while (*np = *dir++ np - snewpath 1023)
+ while ((*np = *dir++) np - snewpath 1023)
++np;
}
}
Index: doscmd.c
===
RCS file: /home/ncvs/src/usr.bin/doscmd/doscmd.c,v
retrieving revision 1.11
diff -u -r1.11 doscmd.c
--- doscmd.c1999/10/13 23:48:35 1.11
+++ doscmd.c1999/11/07 12:50:06
@@ -258,6 +258,7 @@
sigemptyset(uc.uc_sigmask);
sigaltstack(NULL, uc.uc_stack);
+uc.uc_mcontext.mc_onstack = uc.uc_stack.ss_flags;
if (tmode)
tracetrap(REGS);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
doscmd broken on current?
Is doscmd working for anyone on current? Here I just get: - angel:~ doscmd -bx Illegal instruction (core dumped) angel:~ gdb /usr/obj/usr/src/usr.bin/doscmd/doscmd doscmd.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... Core was generated by `doscmd'. Program terminated with signal 4, Illegal instruction. Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Reading symbols from /usr/lib/libc.so.4...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x3e in ?? () (gdb) bt #0 0x3e in ?? () #1 0x2600260 in ?? () Cannot access memory at address 0x260. (gdb) - I have tried it on a single processor and SMP -current and both do the same thing. I had it working a while back, so I think my configuration is ok. Ideas on how to look into this? John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: doscmd broken on current?
In message [EMAIL PROTECTED] John Hay writes: : angel:~ doscmd -bx I've never been able to boot dos with doscmd. I've only ever run programs like sourcer with it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: doscmd broken on current?
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Is doscmd working for anyone on current? Here I just get: - I have tried it on a single processor and SMP -current and both do the same thing. I had it working a while back, so I think my configuration is ok. Ideas on how to look into this? Start by invoking it with the various debug/trace options. I'd guess that it may be broken by the signal-related changes that were made recently. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
