ded@aplvax.UUCP (Don E. Davis) (06/05/85)
We are currently in the midst of converting to 4.2BSD. During this conversion a question popped up which different parts of the documentation seemed to answer differently (so what else is new). We wanted to identify which programs were running with shared text. Unfortunately, we couldn't ascertain this info using "file" or "ps" (and "stat" wasn't even there). The "ld" man page says that loading with a "-n" flag will result in a shared text program via magic number 0410. But a perusal of the kern_exec.c source seemed to indicate that either 0413 or 0410 would result in a shared text program. I compiled a test program with and without the -n option, and the only difference seemed to be that the 0413 magic version had its header padded with zeros up until word 1024. Thereafter, the 0410 and 0413 versions seemed identical. A "file" run on the 0413 version returns "demand paged"; the 0410 doesn't. What is going on here? Is there an easy way to determine which files are running shared text? What are the tradeoffs? Why not make all programs shared text? Thanks? -- Don Davis JHU/APL ...decvax!harpo!seismo!umcp-cs!aplvax!ded ...rlgvax!cvl!umcp-cs!aplvax!ded
chris@umcp-cs.UUCP (Chris Torek) (06/06/85)
Only ``impure'' files aren't shared. The difference between NMAGIC and ZMAGIC (0410 and 0413) files is that the former are paged in before starting, while the latter are demand paged (i.e., you get the first 4K or so ``free'', and fault in the rest of the working set). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
jans@mako.UUCP (Jan Steinman) (06/11/85)
In article <106@aplvax.UUCP> ded@aplvax.UUCP (Don E. Davis) writes: >What is going on here? Is there an easy way to determine which files >are running shared text? What are the tradeoffs? Why not make all programs >shared text? Thanks? As Chris Torek points out in another article, both NMAGIC (0410) and ZMAGIC (0413) files are sharable. The remaining need for "impure" OMAGIC (0407) files has not been addressed. OMAGIC files are not sharable because their code space is writable. Two uses are old binaries, and new programs that, for some reason, require writes to code space. Until the mmap() calls become generally available (4.3?) there is a need for OMAGIC files. We are currently writing extremely fast assembly code for the NS32000 under UNIX, and want to take advantage of the short abslolute addresses starting at location zero. The only way we know to have writable data below the code space is to use OMAGIC format. Note that I am not advocating dynamic code modification; I simply need more control over data - code layout than UNIX gives me. When facilities for explicit control of memory management are available, OMAGIC can probably be put to bed, at least for new code. -- :::::: Jan Steinman Box 1000, MS 61-161 (w)503/685-2843 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::
ignatz@aicchi.UUCP (Ihnat) (06/12/85)
In <814@mako.UUCP>, Jan Steinman comments: > "...their code space is writable. Two uses > are old binaries, and new programs that, for some reason, require > writes to code space. ... " Like programs to be run under interactive, intrusive debuggers. > The only way we know to have writable data below the code > space is to use OMAGIC format. Note that I am not advocating > dynamic code modification; I simply need more control over > data - code layout than UNIX gives me. > > When facilities for explicit control of memory management are available, > OMAGIC can probably be put to bed, at least for new code. I assume, from your comments, that you're on a BSD or BSD-derived site. I would like to point out that, although it's not yet widely documented, the COFF (Common Object File Format) loader (admittedly only on System V) has a fairly rich range of link editor directives, which give the programmer good control over the final composition of the executable image and its memory layout. -- Dave Ihnat Analysts International Corporation (312) 882-4673 ihnp4!aicchi!ignatz
guy@sun.uucp (Guy Harris) (06/17/85)
> > "...their code space is writable. Two uses > > are old binaries, and new programs that, for some reason, require > > writes to code space. ... " > Like programs to be run under interactive, intrusive debuggers. I.e., a debugger that runs in the same address space as the program being debugged? If a debugger running outside that address space uses "ptrace" to write to the code space, the code will be made non-sharable (unless it's already being shared) and briefly made writable while the word in the code space is changed. > > The only way we know to have writable data below the code > > space is to use OMAGIC format. > I assume, from your comments, that you're on a BSD or BSD-derived site. I > would like to point out that, although it's not yet widely documented, > the COFF (Common Object File Format) loader (admittedly only on System > V) has a fairly rich range of link editor directives, which give the > programmer good control over the final composition of the executable image > and its memory layout. I would like to point out that the System V "exec" system call ignores all the information stuck in the executable image indicating the final composition of the executable image and its memory layout; it requires an executable image to consist of a text segment and a data segment further subdivided into an initialized data segment and a zero-filled BSS segment. The text segment may be omitted. The linker supports lots of control over the format of an executable image, but this is for the purpose of cross-development. "Mainstream" UNIX hasn't added any new capabilities to its executable image format since shared text segments were introduced. (The "exec" code in S5 isn't much changed from the V7 "exec" code; it just throws away the COFF header and uses the "optional header" as an old-style UNIX executable image header.) Guy Harris
boyd@basser.oz (Boyd Roberts) (06/18/85)
In article <2314@sun.uucp> guy@sun.uucp (Guy Harris) writes: > >I.e., a debugger that runs in the same address space as the program being >debugged? If a debugger running outside that address space uses "ptrace" to >write to the code space, the code will be made non-sharable (unless it's >already being shared) and briefly made writable while the word in the code >space is changed. > We have a debugger that runs in the address space of the debugged program. It understands C (at the source level) and leaves adb, sdb and dbx for dead. However it is VAX specific. It's called 'bedbug'. It boots itself and the debugged program inside the one process. There are no nasty kernel hacks needed to support it. We use it and it works. The others are only useful to see that r11 has a bad pointer in it. Real bugs require 'bedbug'. But, with V8 you've got 'pi'. THE blit debugger! Those nasty bugs won't stand a chance. Those clever lads at research have done well. Boyd Roberts. ...!decvax!mulga!basser.oz!boyd ...!seismo!munnari!basser.oz!boyd (better).