george (01/03/83)
This site has a VAX running 4.0 BSD with a 2K byte block size. On this system demand load format is the default for "a.out" files. In such files the first block contains an eight word (i.e. 32 byte) header. The remainder of that block (i.e. 2016 bytes) is unused and contains zeros. I suspect that this wastes considerable storage space along with some processor and I/O time. I do not know whether there are different more recent "a.out" formats. I have a suggestion for a remedy. I have only given it brief consideration, so comments and discussion might be in order. The remedy involves a new demand load format in "a.out" files along with some corresponding kernel changes. The first eight words of the file contain the standard header. The ninth word will be discussed later. The tenth word of the file contains the tenth word of the load image. Succeeding words of the load image before "_etext" correspond to succeeding words in the file. The data segment follows normally. The ninth word contains an offset in the file to a location somewhere after the data segment image where the first nine words of the load image can be found. A copy of the first nine words of the executing image could be stored in some convenient data structure. Perhaps an enlarged "user" would due. George Rosenberg
thomas (01/04/83)
Even easier - start the program, not at 0, but at 0x10 (thus bypassing the header). Then the first block could contain code. This should be a pretty simple mod to the loader, kernel, etc. (debuggers, ....) The problem with the proposed scheme is that each time page 0 is needed, two reads must be done, and the results combined (that's what demand paging means - no copy is kept anywhere). The exec header is already kept in the user structure. =Spencer
dmmartindale (01/04/83)
Actually, the loader already supports everything you need: the -T flag can handle non-zero text origins, and -e will set a non-zero entry point. It would seem that all you need to do is reserve another "magic number" to indicate a demand-paged a.out whose block numbers are handled without the 1-block offset, change the kernel to support this, and change the loader to have a single-letter flag which sets the magic number to the newly-selected value and sets up the text origin and entry point defaults appropriately. Shouldn't take long at all. Oh yes, better have adb/sdb know about this too. This might be more work than the actual kernel and loader changes. Dave Martindale
emrath (01/07/83)
#R:idis:-17700:uiucdcs:13700013:000:1071 uiucdcs!emrath Jan 7 00:57:00 1983 Maybe this isn't the place, but the last note mentioned ld's -T option. I have tried using this a couple times and everything blows up when I do. Could someone please explain what it actually does? I am running some compatibility mode code (loaded dynamically). To reserve pdp-11 addressing space, I have an assembler module that is nothing but: .text zero: .space 0200000 It all works fine with this as the first module "ld'ed", the -N option to make the whole mess r/w and the -e option to set the start address. But it takes a godawful long time to load because of the 64K chunk of zeros at the front. From the manual it looked like maybe the T option would allow me to eliminate this essentially bss space, but I can't get it to work. Is there any way I can? As a solution I have been thinking of writing a separate small program which manually loads the pdp-11 code loader/emulator by doing the appropriate "brk" call, then loading the program skipping over the first 0200000 bytes (of 0's) and finally transferring to it. P. Emrath - EUREKA Group - U of IL
dmmartindale (01/10/83)
Using the -T option of ld will relocate the code as if it started at some particular text origin other than zero, but if you execute an a.out containing such code it still gets loaded at location zero. One possible way around this would be to have a small piece of position-independent assembler code which copies the code from where it got loaded to the address that it expects to be executed from, and then jumps to it.