Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!brl-adm!adm!rbj@icst-cmr.arpa From: rbj@icst-cmr.arpa (Root Boy Jim) Newsgroups: comp.unix.wizards Subject: Aliasing text and data segments of a process Message-ID: <11476@brl-adm.ARPA> Date: 25 Jan 88 21:31:42 GMT Sender: news@brl-adm.ARPA Lines: 33 From: Doug Gwyn In article <730@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes: >loads the .o file as data, and then branches to the start of the text area >of the .o file This cannot possibly work on an architecture that enforces the distinction between Instruction and Data spaces. While true, most such machines do not *insist* on enforcing the distinction, or provide mechanisms around it where appropriate. Thus is is possible to build three or four types of executables on a given system: (1) Text and Data glommed together with only limits protection. (2) Text sharable (and thus unmodifyable), data separate & possibly executable. (3) Text and Data separate in separate I/D spaces. Here they share the same address range and as Doug mentions, never the twain shall meet. (4) Demand paged, which is more or less like (2) above. Each format has its own advantages and drawbacks. If you want to set breakpoints in code, you must use the first type. If you want to dynamically load code, you must either use this format, or execute from data space if possible. This kind of stuff tends to vary across machines and systems. The split I/D space PDP-11 is perhaps a bad example, as it is (or was) possible to build other format executables, but I'm sure Doug *has* seen machines where this is impossible. (Root Boy) Jim Cottrell National Bureau of Standards Flamer's Hotline: (301) 975-5688 I feel like a wet parking meter on Darvon!