Mercurial > hg > xemacs-beta
view dynodump/README @ 4695:fee33ab25966
Add arglist info for autoloaded functions and macros.
lisp/ChangeLog addition:
2009-09-20 Aidan Kehoe <kehoea@parhasard.net>
Add arglist information to docstrings for autoloaded functions and
macros.
* hyper-apropos.el (hyper-apropos-get-doc):
Treat autoload docstrings like subr docstrings; correct the regexp
used.
* help.el (describe-function-show-arglist):
This no longer treats autoloads specially.
(function-arglist): Treat autoload docstrings like subr docstrings.
(function-documentation): Treat documentation strings that are
zero-length after the arglist has been removed as indicating a
lack of documentation.
* cl-macs.el (case):
(ecase):
(typecase):
(etypecase):
(block):
(return):
(return-from):
(progv):
(lexical-let):
(lexical-let*):
(remf):
(callf):
(callf2):
(define-modify-macro):
(deftype):
(define-compiler-macro):
Rely on the autoload code to always show an arglist for these
functions, don't supply an ad-hoc one in the docstring.
These changes are for the most obvious functions; there are some
missed that would require changing argument names in the docstring
or in the function bodies.
* autoload.el (make-autoload):
Add arg list information to the doc string, using the same
approach as for subrs.
author | Aidan Kehoe <kehoea@parhasard.net> |
---|---|
date | Sun, 20 Sep 2009 23:50:05 +0100 |
parents | 376386a54a3c |
children |
line wrap: on
line source
DYNODUMP -------- Dynodump, not to be confused with DinoTurd (as seen in Jurassic Park), is a shared object that provides one function: int dynodump(char *new_file); dynodump(), called from a running program will write a new executable in new_file a la unexec() in GNU Emacs. The difference lies in the relocations. dynodump() will create an image with any relocations (which were performed by the run-time dynamic linker) undone. This allows the new image to be run in a different environment. There is, however, one potentially major caveat. If a symbol reference gets updated during the running of the calling program, its updated value will be lost. An example (with additional blank lines for legibility): $ cat lib.c char _foo[] = "hello"; char _bar[] = "world"; $ cc -G -o lib.so lib.c $ cat prog.c extern char _foo, _bar; int beenhere = 0; char * foo = &_foo; char * bar = &_bar; int main(void) { (void) printf("%d: foo = %x\n", beenhere, foo); (void) printf("%d: bar = %x, ", beenhere, bar); if (!beenhere) { beenhere = 1; bar++; dynodump("newfile"); } (void) printf("%x\n", bar); } $ cc -o prog prog.c -R. lib.so dynodump.so $ ./prog 0: foo = ef7503cc 0: bar = ef7503d2, ef7503d3 $ ./newfile 1: foo = ef7503cc 1: bar = ef7503d2, ef7503d2 Notice that in the run of newfile, bar points at "world" instead of the perhaps expected "orld". Dynodump supports sparc, intel, and power pc architectures. Dynodump is buildable with GNU make and gcc. If it works for you with these tools, let me know. unexec() -------- Also supplied is an unexsol2.c which belongs in the XEmacs src directory with the other unex*.c files. The src/s/sol2.h should be have the following added to it: #ifdef UNEXEC #undef UNEXEC #endif #define UNEXEC unexsol2.o This unexec() will attempt to dlopen() the dynodump.so to find the dynodump function. The default is "../dynodump/dynodump.so" which should be appropriate for the typical XEmacs build (unless you used configure to set up separate build and source trees). You may change it by setting the DYNODUMP environment variable to the full path of the dynodump shared object. Other notes: If you're using the 4.0 C compiler from Sun, you should arrange to shut off the incremental linker. This is done with the -xildoff option to the compiler. The common.mk and testsuite/Makefile files have commentary and ready made lines for uncommenting for this purpose. If you're interested in playing with the UltraSPARC specific options to the aforementioned compiler, then the same makefiles have some commentary and flags settings to point you in that direction. Questions: dynodump() was developed by Rod.Evans@Eng.Sun.COM and Georg.Nikodym@Canada.Sun.COM. If you have questions, feel free to ask them but be aware that Rod, "don't know jack about emacs."