jca@pnet01.cts.com (John C. Archambeau) (04/24/89)
I have found the problem with it and it turns out to be a nasty bug in the
object code generator for switch statements. If you compile with the -S
option, the assembly code looks perfectly legal (it probably is), but if you
take a debugger to the generated code for fsck.c, it turns out that the switch
code does not match that (operand wise) to the assembly code.
I have a sneaking suspicion that there are such beasts as Turbo C 1.51, 1.52,
etc. floating around out there with patches that Borland has put in. It's the
only logical explanation as to my problem in building Minix with 1.5.
For you Turbo C 1.5 people who have successfully built Minix without this
problem, did you have to patch your compiler for it to work?
For those of you trying to cross compile with 1.5 and for some strange
bizarre reason commands you get with the opening menu are illegal, try adding
this debugging code to default in main of fsck.c
default:
if (command == '=')
printf ("\nEeek! Time to yell at Borland.\n");
printf ("Illegal command.\n");
continue;
If the switch code was working properly, the first printf after the if in
default should NEVER be printed since there's a case '=' which is used to
start up the kernel.
(Oh, thanks to that person who sent me mail saying that it might be a bug with
TC, but I didn't want to believe it...now I believe it.)
JCA
UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca
ARPA: crash!pnet01!jca@nosc.mil
INET: jca@pnet01.cts.commjw@vaxine.UUCP (Mike Wilt) (04/28/89)
In article <4105@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes: >I have found the problem with it and it turns out to be a nasty bug in the >object code generator for switch statements. If you compile with the -S >option, the assembly code looks perfectly legal (it probably is), but if you >take a debugger to the generated code for fsck.c, it turns out that the switch >code does not match that (operand wise) to the assembly code. > [more stuff] I isolated that bug and sent a complete description to Borland. They said they couldn't reproduce it. I didn't feel like sending them the entire source to my program, so I let it go. It is apparently a problem with the way the assembler-end of the compiler generates code. It was making a tight loop to test some of the cases, and the jump-back instruction was pointing one instruction after the test. The result is that it runs the loop without actually testing anything. Inside the loop, there was a JNE followed by JMP. The assembler code generated by the -S option had JE. I believe the assembler pass at the back end of the compiler substituted JNE+JMP without correcting the offset from the end of the loop back to the beginning. It was easy to make this bug disappear, because rearranging the cases would move branches between the loop tests and the jump table. It was not in 1.0x, it appeared in 1.5, and it may be gone in 2.0. I assume their tech support guys didn't know about it, at least not when I was trying to report it. Mike
jca@pnet01.cts.com (John C. Archambeau) (05/08/89)
mjw@vaxine.UUCP (Mike Wilt) writes: >In article <4105@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes: >>I have found the problem with it and it turns out to be a nasty bug in the >>object code generator for switch statements. If you compile with the -S >>option, the assembly code looks perfectly legal (it probably is), but if you >>take a debugger to the generated code for fsck.c, it turns out that the switch >>code does not match that (operand wise) to the assembly code. >> >[more stuff] > >I isolated that bug and sent a complete description to Borland. They said >they couldn't reproduce it. I didn't feel like sending them the entire source >to my program, so I let it go. It is apparently a problem with the way the >assembler-end of the compiler generates code. It was making a tight loop to >test some of the cases, and the jump-back instruction was pointing one >instruction after the test. The result is that it runs the loop without >actually testing anything. Inside the loop, there was a JNE followed by JMP. >The assembler code generated by the -S option had JE. I believe the assembler >pass at the back end of the compiler substituted JNE+JMP without correcting >the offset from the end of the loop back to the beginning. It was easy to make >this bug disappear, because rearranging the cases would move branches between >the loop tests and the jump table. > >It was not in 1.0x, it appeared in 1.5, and it may be gone in 2.0. I assume >their tech support guys didn't know about it, at least not when I was trying >to report it. > >Mike Would you mind telling us (especially me), how you corrected this bug? I have taken a good look at the code after calling Borland and this bug just doesn't exist. I have dumped both the -S generated code and have cranked the .obj code through D86 and listed it to printer. Everything is kosher. My guess is that A86 isn't doing something correctly or build.c has an error in it. Right now I'm just plain stuck on what to do about this problem and everything is pretty much halted until I resolve this problem (and I have a 10 MB partition waiting for Minix 1.3). I figure it this way, if the people who have written the Turbo C 1.5 articles have done it, then the bug is not in the compiler and the only patch for Turbo C 1.5 is for the library module initgraph. The only other common denominator is the fact that I'm not using MASM which might be botching up the cs register when I go to link up the A86 code and Turbo C code. JCA UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca ARPA: crash!pnet01!jca@nosc.mil INET: jca@pnet01.cts.com