hartzell@boulder.colorado.edu (George Hartzell) (11/20/89)
I am working on a port of ELK (a scheme interpreter) to our M2000
running RISCos 4.01 with the 2.10 beta compilers. I have everything
but "dynamic loading" working (apparently this is also known as
fasl'ing). Here is what the author says is required to support
CAN_DYNAMIC_LOAD.
Dynamic loading:
Define CAN_LOAD_OBJ if the target system enables dynamic loading
of object files. This requires that the system linker (/bin/ld)
supports the -A and -T options for incremental loading and that
the data space in the interpreter is executable, i.e. that it is
possible to derive a function pointer to an object that has been
loaded into data space. In addition, it requires that your system
supports the BSD-style a.out format; the current release of the
software does not support dynamic loading for other a.out file
formats (such as COFF).
I've written the support for the MIPS object format and Third Eye
symbol tables, and have ld -A -T working (after building G0 copies of
a library or two...). I can read in the resulting OMAGIC file, and
can determine the address of a function that I want to call. The
result is always a segmentation fault.
Before I spend too much more time figuring out why this isn't working,
is there someone out there who can tell me IF IT IS POSSIBLE? e.g.
can I call a function pointer that points into my data space? Do I
have to do something special to do this? Is it impossible?
Any help would be appreciated.
g.
George Hartzell (303) 492-4535
MCD Biology, University of Colorado-Boulder, Boulder, CO 80309
hartzell@Boulder.Colorado.EDU ..!{ncar,nbires}!boulder!hartzellhartzell@boulder.Colorado.EDU (George Hartzell) (11/21/89)
In article <14057@boulder.Colorado.EDU>, hartzell@boulder (me) writes: > >I've written the support for the MIPS object format and Third Eye >symbol tables, and have ld -A -T working (after building G0 copies of >a library or two...). I can read in the resulting OMAGIC file, and >can determine the address of a function that I want to call. The >result is always a segmentation fault. > >Before I spend too much more time figuring out why this isn't working, >is there someone out there who can tell me IF IT IS POSSIBLE? e.g. >can I call a function pointer that points into my data space? Do I >have to do something special to do this? Is it impossible? > Ok, it works just fine. The problem was that I a missing lseek before I read in the text segment from the "ld -A'd" .o file. Oops... Thanks to lattanzi@decwrl.dec.com and earl%wright.mips.com@mips.com for responding to my message. They both suggested that a cache flush might be in order. In light of the larger goof (see above) I haven't figured out how badly it is needed. I will experiment with it though. g. George Hartzell (303) 492-4535 MCD Biology, University of Colorado-Boulder, Boulder, CO 80309 hartzell@Boulder.Colorado.EDU ..!{ncar,nbires}!boulder!hartzell
grunwald@foobar.colorado.edu (Dirk Grunwald) (11/22/89)
How do you force a cache flush? Will a simple O/S call do it as part of the O/S overhead?
cprice@mips.COM (Charlie Price) (11/22/89)
In article <14134@boulder.Colorado.EDU> grunwald@foobar.colorado.edu writes: > >How do you force a cache flush? Will a simple O/S call do it as part >of the O/S overhead? RISC/os, the MIPS OS, has calls to let any user process invalidate (clean, flush) portions of the process' virtual space. The call is: cacheflush(start_addr, nbytes, which_caches) Say "man cacheflush" to receive greater enlightenment. The only cache flushing that you are likely to need from the user level is to get rid of "stale" entries in the instruction cache. The i-cache can contain out-of-date entries when the user has done either a store or a read(2) into locations used as instructions. The i-cache isn't updated automatically as a result of CPU store instructions or DMA. When you "flush" the address in the i-cache, it is marked invalid and the next i-fetch takes a cache miss and gets the (new) instruction from main memory. Caution. MIPS cpu's have a per-page bit in the memory mapping hardware that allows accesses mapped through the translation buffer to bypass the cache and always go to main memory. RISC/os offers a user-level service to make pages of the process' virtual space "uncached" by setting the no-cache bit in the page table entry. Utter "man cachectl" to find out about this service. You might be tempted to avoid the hassles of invalidating the i-cache in the right places by making the entire region you use uncached. If you do any loops at all executing from uncached locations is going to be VERY SLOW. The overhead of invalidating the cache entries is probably less. -- Charlie Price cprice@mips.mips.com (408) 720-1700 MIPS Computer Systems / 928 Arques Ave. / Sunnyvale, CA 94086
zs01+@andrew.cmu.edu (Zalman Stern) (11/25/89)
Here's what it took to get cache flushing under Ultrix 3.1 on a DECstation
3100:
#ifdef ultrix
if (cacheflush(e->text, e->totalsize, BCACHE) != 0) {
#else
/* Ultrix 3.1 does not have cacheflush in libc.a, however, the kernel on my
* machine implements it and it is needed to make doindex work...
*/
#include <sys/syscall.h>
#include <sys/sysmips.h>
if (syscall(SYS_sysmips, MIPS_CACHEFLUSH, e->text, e->totalsize,
BCACHE, 0) == -1) {
#endif
Sincerely,
Zalman Stern
Internet: zs01+@andrew.cmu.edu Usenet: I'm soooo confused...
Information Technology Center, Carnegie Mellon, Pittsburgh, PA 15213-3890