williams@kirk.DEC (John Williams 223-3402) (03/04/86)
In response to George Tomasevich: I will say right off that bat that I haven't tried this. It appears to me, however, that the problem is how C handles memory management. This seems to me to be very machine dependent, even compiler dependent. I'm sure that the compiler, in any event, would spit all kinds of warnings at you. Perhaps a way around it would be to gain access somehow to the memory management register, have a function that flips a bit just before calling the data code, and cleans up afterwards. Perhaps the problem is that C allows you to have identically named functions and variables, but you could get around that as well. Perhaps the function that calls the coded data should be written in assembly, to account for the machine dependency, with conditional linking to maintain portability. I'm not convinced that the whole thing can be done in C, but by the same token, I don't see that the whole thing has to be written in assembly, either. John.
nathan@mit-eddie.MIT.EDU (Nathan Glasser) (03/06/86)
A couple of years ago there was a "contest" on usenet for the most
obscure/unreadable C code. The winner was a program which was of the form
char *main[] = { ... };
Where ... is a sequence of bytes. I remember that they were given in
all the possible ways: some in decimal, some octal, some hex, some characters.
There was only 1 file, and it compiled and ran fine on vaxen, and I think
was supposed to work on pdp's too. I think it did some little tiny
animated type thing using backspaces to erase and move something across
the line.
Anyway, isn't this putting code into the data space?
Nathan Glasser
nathan@mit-eddie.uucp
nathan@mit-xx.arpalaw@petsd.UUCP (Steve Law) (03/10/86)
> In response to George Tomasevich: > I had missed that one. > This seems to me to be very machine dependent, even compiler > dependent. I'm sure that the compiler, in any event, would spit all > kinds of warnings at you. Perhaps a way around it would be to gain > access somehow to the memory management register, have a function that > flips a bit just before calling the data code, and cleans up afterwards. > Perhaps the problem is that C allows you to have identically named > functions and variables, but you could get around that as well. > UNIX System V link editor (ld) allows one to put functions in the .data section of a COFF file. All you need to do is to create a ld command file (also called ifile). For example, the following ifile: SECTIONS { .data: { file1.o (.text) /* file1.c, file2.c file3.c contain */ file2.o (.text) /* the functions text that to be */ file3.o (.text) /* placed in the .data section of */ ... /* the final a.out */ } } and the following command lines: cc -c file1.c file2.c file3.c cc -N otherfiles.c ifile will create an a.out which will have all the functions of file[123].c in the .data section instead of .text section. One can also use ifile(s) to do the following: - place data in .text - create dummy sections (e.g., store history info) - create holes within sections - align sections - merge sections - subsystem linking and many others. It is a very powerful tool, but some of its features are not well documented!!! Steve Law --*-------*-------*-------*-------*-------*-------*-- Name: I. S. Law (Steve) UUCP: ihnp4!vax135!petsd!law ARPA: vax135!petsd!law@BERKELEY US Mail: MS 314B; Concurrent Computer Corp. 106 Apple St; Tinton Falls, NJ 07724 Phone: (201) 758-7280 --*-------*-------*-------*-------*-------*-------*--
lasse@daab.UUCP (Lars Hammarstrand) (03/18/86)
In article <728@petsd.UUCP> law@petsd.UUCP writes: >> In response to George Tomasevich: >> >> >UNIX System V link editor (ld) allows one to put functions in the .data etc, etc ..... > > - place data in .text > - create dummy sections (e.g., store history info) > - create holes within sections > - align sections > - merge sections > - subsystem linking > >and many others. It is a very powerful tool, but some of its features >are not well documented!!! > GOOD, but now the rest of the world wonder where you can read more about it!!?? Lars Hammarstrand.
law@pecnos.UUCP (Steve Law) (03/21/86)
In article <200@daab.UUCP> Lars Hammarstrand writes: > In article <728@petsd.UUCP> law@petsd.UUCP writes: > >>UNIX System V link editor (ld) allows one to put functions in the .data > etc, etc ..... > > GOOD, but now the rest of the world wonder where you can read more about it!!?? COFF and COFF-based link editor (ld) are being used in both UNIX and UNIX/RTR systems. Most of the COFF and ld features (e.g., ifile) can be found in the COFF section and the LINK EDITOR section of UNIX System V Release 2.0 Support Tool Guide This document can be purphased from AT&T. Since UNIX/RTR exercises more features of COFF and ld than UNIX, additional features them can be found in one of the UNIX/RTR user's manuals. I don't know the exact volume number. They used to be in volume 3 of the old user's manuals. Steve Law
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/23/86)
In article <200@daab.UUCP> lasse@unix.UUCP (Lars Hammarstrand) writes: >In article <728@petsd.UUCP> law@petsd.UUCP writes: >>> In response to George Tomasevich: >>UNIX System V link editor (ld) allows one to put functions in the .data > etc, etc ..... >> - place data in .text >> - create dummy sections (e.g., store history info) >> - create holes within sections >> - align sections >> - merge sections >> - subsystem linking >>and many others. It is a very powerful tool, but some of its features >>are not well documented!!! >GOOD, but now the rest of the world wonder where you can read more about it!!?? Check out the "Link Editor" section of AT&T's UNIX System V Support Tools Guide, select number 307-108. The "COFF" section of the same Guide is also relevant.