Date: Tue, 10 Jun 1997 11:15:37 +0300 (IDT) From: Eli Zaretskii To: Nate Eldredge cc: djgpp AT delorie DOT com Subject: Re: DJGPP runs bogus binaries In-Reply-To: <199706092327.QAA04931@adit.ap.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 9 Jun 1997, Nate Eldredge wrote: > I spent hours suspecting a bug in Make before finding a Linux ELF binary in > the directory of something I was trying to port. Make would try to run it, > it would be run (!) and of course crash. (As an aside, it *completely* > wedged the system, requiring cold boot. Isn't protected mode supposed to > prevent this?) You are missing the real reason for the crash: it's DOS that generates the exception, not Make. DJGPP doesn't do anything special to invoke what seems to be a non-DJGPP program, it just calls the DOS Exec function. It's the responsibility of the OS to decide whether a given file is an executable and how it should be run, but DOS only knows about .EXE files with their "MZ" signature, and assumes that everything else is a .COM-style image. So it loads your ELF file, jumps to location 100h and promptly departs to the never-never land. Since DOS is real-mode code, you don't get any protection. > I notice a comment in the source (src/libc/dos/process/dosexec.c) indicating > that this is a known problem. Perhaps some effort should be put into fixing > it. It doesn't seem that difficult; there are presumably magic numbers and > such to check for. It might be a good idea to add more safeguards if they don't bloat the code too much. It would be swell if you could write the additional code and post it. I don't know anything about magic numbers beyond what's already in `dosexec' (for those formats that DJGPP supports), and nobody else seems to be willing to mess with that code. The comments there that point to issues which should be fixed are for those who know how to fix them without rewriting major parts of the OS; I don't. Please also note that DJGPP's `spawn' and `system' don't skip any tests (AFAIK) in this context that other compilers do: all of them rely on DOS to figure out how the program should be invoked. A C library can cover up a basic OS deficiency only up to a point. > or at *least* if this problem could be documented better. Could you please review the docs of `system' and `spawnXX' family and suggest where the docs should be amended? Thanks.