elston@edwards-saftd-2.af.mil (03/16/91)
We have been struggling with an apparent memory conflict. In the process of investigating this conflict we have tried changing the default linker loader instructions. Our system (68020 VME running System V 2.3 with 2 Megabytes of physical memory on the main processor and another 2 Meg on another node) came with the following default.ld MEMORY { valid : org = 0x0, len = 0x200000 } SECTIONS { .text : {} GROUP ALIGN(65536) : { .data : {} .bss : {} } } When we change the alignment from 64K to something like 128 bytes or over 128K and compile with the -g option then we get error messages like prog: w\N(ILX^O.<UU/: cannot open prog: _|^LB.^?x^L.^D^?xl,: not found prog: syntax error at line 5: `(' unexpected This implies (at least to me) that the text area is being corrupted with the line number information, the symbol table information, or just the .data and .bss sections. Trying to debug with sdb will allow us to see the source code as it appears in the original but when trying to run under sdb we get Returned from execve: Exec format error Cannot ptrace child process; try again.: No such process It seems to be connected with the problem of running it from the command line. Any ideas? Why should the alignment make such a difference? Any help would be appreciated. -- ############################################################################## # A mind is a terrible thing to waste - elston@edwards-saftd-2.af.mil # # Thank goodness mine's all used up. # # # # If the author has expressed any opinions here they are purely # # accidental and should be ignored. # ##############################################################################
thomas@nexus.se (03/26/91)
In article <1991Mar15.091211.32@edwards-saftd-2.af.mil> elston@edwards-saftd-2.af.mil writes: We have been struggling with an apparent memory conflict. In the process of investigating this conflict we have tried changing the default linker loader instructions. Our system (68020 VME running System V 2.3 with 2 Megabytes of physical memory on the main processor and another 2 Meg on another node) came with the following default.ld MEMORY { valid : org = 0x0, len = 0x200000 } SECTIONS { .text : {} GROUP ALIGN(65536) : { .data : {} .bss : {} } } When we change the alignment from 64K to something like 128 bytes or over 128K and compile with the -g option then we get error messages like prog: w\N(ILX^O.<UU/: cannot open prog: _|^LB.^?x^L.^D^?xl,: not found prog: syntax error at line 5: `(' unexpected This implies (at least to me) that the text area is being corrupted with the line number information, the symbol table information, or just the .data and .bss sections. Trying to debug with sdb will allow us to see the source code as it appears in the original but when trying to run under sdb we get Returned from execve: Exec format error Cannot ptrace child process; try again.: No such process It seems to be connected with the problem of running it from the command line. Any ideas? Why should the alignment make such a difference? Any help would be appreciated. -- First of all, you can't have an alignment of less than the pagesize if you have shared text (the default). The -N flag to ld makes the text writeable. Using this you don't have to align the sections at all. The symtoms you are experiencing are due to the way the shell handles shell scripts. If you have an unsupported alignment the kernel returns from the execve with ENOEXEC. As the shell recognizes that the execve failed, it assumes the executable to be a shell script and forkes off a shell and hands the file to it as a script. The error messages comes from this shells fruitless attempts to interpret the content of the file. This is also why the behaviour is different when when running it from a shell and running it under sdb, sdb recognizes that the file isn't executable. As for having an alignment of 128k the problem might be that Motorola hasn't bother fixing their braindamaged exec(). At least in V.2 they couldn't handle any alignment other than 64k. The fix was very simple and we fixed it for our port so it could handle any alignment greater than or equal to the page size. Then again, one might ask why anyone would use anything aother than the default alignment. In our case we used an alignment of 8k and had hardware that used either 2k or 8k page size. At one moment we also wanted to execute binaries from a Motorola system that used 64k. Hope this clarifies some of the mystery. Thomas -- Real life: Thomas Tornblom Email: t_tornblom@nexus.se Snail mail: Communicator Nexus Phone: +46 18 171814 Box 857 Fax: +46 18 696516 S - 751 08 Uppsala, Sweden