irwin@uvmark.uucp (Frank Irwin) (02/16/91)
I'm trying to make ld bind shared object files into the output object, so
that all system calls will use our malloc() instead of the system malloc().
To do this, I use the -bnoautoimp -berok -bnogc options to ld. However,
bind never seems to complete. Doing a ps:
upix 9665 18551 0 10:43:55 pts/39 0:00 cc -O -bnso -berok -bnogc genro.o uvmalloc.o -o genro
upix 11971 36802 34 10:43:55 pts/39 19:39 /usr/lib/bind QUIET NOLOADMAP
upix 36802 9665 0 10:43:55 pts/39 0:00 ld -H512 -T512 -bhalt -bnso -berok -bnogc -o genro /lib/crt0.o genro.o uvmalloc.
If I leave out the -bnogc option, it binds fine, but running genro results in:
Could not load program genro
Error was: Exec format error
Any ideas would be greatly appreciated.
Frank
--
====================================================================
Frank Irwin | "I'll bet $50 on that flush."
Vmark Software, Inc. | Whooooosh!
..uunet!merk!uvmark!irwin | "Aaaaiiiieeee! Not *that* flush!"bengsig@dk.oracle.com (Bjorn Engsig) (02/18/91)
Article <1991Feb15.190657.47304@uvmark.uucp> by irwin@uvmark.uucp (Frank Irwin) says: |I'm trying to make ld bind shared object files into the output object, so Well, the binder is a tricky one to use when you step just a bit aside of it's normal use. And unfortunately the documentation doesn't help you very much. |that all system calls will use our malloc() instead of the system malloc(). Since libc.a is not much more that one big shared object (ever did ar tv on it?) you would expect that you cannot replace a module by another one. Also, and this is important, this is definately not according to ANSI C. If you don't want malloc(), use your_malloc() in stead. | |To do this, I use the -bnoautoimp -berok -bnogc options to ld. However, |bind never seems to complete. It is sometimes very time consuming, in particular if you are low on real memory. If you are (also) low on paging you'll get killed by signal 9. | |Could not load program genro |Error was: Exec format error Some of the options to the linker are only supposed to be used when IBM is linking the aix kernel. | |Any ideas would be greatly appreciated. The best one is to use your_malloc() all over your code. That's guaranteed to work; but it does of course need to call malloc() eventually to get the memory, or you could try to implement it using shared memory calls, which is also hard since there is no brk() equivalent on shared memory. -- Bjorn Engsig, ORACLE Corporation, E-mail: bengsig@oracle.com, bengsig@oracle.nl "Stepping in others footsteps, doesn't bring you ahead"
marc@marc.watson.ibm.com (Marc Auslander) (02/18/91)
In article <1991Feb15.190657.47304@uvmark.uucp> irwin@uvmark.uucp (Frank Irwin) writes: ... >To do this, I use the -bnoautoimp -berok -bnogc options to ld. However, >bind never seems to complete. Doing a ps: ... >If I leave out the -bnogc option, it binds fine, but running genro results in: >Could not load program genro >Error was: Exec format error The only option you should be using is -bnoautoimp. -bnogc will attempt to make a monstrous output module containing the whole contents of all the libraries you've included. -berok suppresses error messages AND marks the module non-executable. It is what is causing the "Exec format error". Make sure your program which defines malloc also defines free and realloc. (If you are using -berok because you get undefined errors you will have to fix the errors.) -- Marc Auslander <marc@ibm.com>
irwin@uvmark.uucp (Frank Irwin) (02/19/91)
In article <1255@dkunix9.dk.oracle.com> bengsig@dk.oracle.com (Bjorn Engsig) writes: >Article <1991Feb15.190657.47304@uvmark.uucp> by irwin@uvmark.uucp (Frank Irwin) says: >Since libc.a is not much more that one big shared object (ever did ar tv on it?) >you would expect that you cannot replace a module by another one. Also, and >this is important, this is definately not according to ANSI C. If you don't >want malloc(), use your_malloc() in stead. But I also want the system functions to use our malloc(). We've experienced memory space corruption when our malloc() and the system malloc() are both used. >|To do this, I use the -bnoautoimp -berok -bnogc options to ld. However, >|bind never seems to complete. >It is sometimes very time consuming, in particular if you are low on real >memory. If you are (also) low on paging you'll get killed by signal 9. We've got 32MB of real memory, and 128MB paging space. >The best one is to use your_malloc() all over your code. That's guaranteed >to work; but it does of course need to call malloc() eventually to get the >memory, or you could try to implement it using shared memory calls, which >is also hard since there is no brk() equivalent on shared memory. No, our malloc() doesn't call the system malloc(). We use brk() and sbrk() to get the space, then manage it ourselves. On machines which don't use shared libraries, this has not given us a problem. Actually, we also have no problems with machines that do have shared libraries, if they allow us to bind in everything at load time, as SunOS4.1 does. -- ==================================================================== Frank Irwin | "I'll bet $50 on that flush." Vmark Software, Inc. | Whooooosh! ..uunet!merk!uvmark!irwin | "Aaaaiiiieeee! Not *that* flush!"
jsalter@panews (02/19/91)
In article <1991Feb18.193126.26425@uvmark.uucp> irwin@uvmark.uucp (Frank Irwin) writes: >But I also want the system functions to use our malloc(). We've experienced >memory space corruption when our malloc() and the system malloc() are both >used. In terms of shared libraries, you can't. This has been discussed before. It's because of the pre-bound shared libraries in AIXv3. Though your routines may use your malloc(), the system libraries will use the system malloc(). There is no way around this as of this time. Open an APAR if you think it needs it. In terms of unshared libs, I just found the following note (dated Dec. 13th): Newsgroups: comp.unix.aix Subject: Re: Can the RS6000 do NON-dynamic linking? Message-ID: <MARC.90Dec13113545@marc.watson.ibm.com> Date: 13 Dec 90 16:35:45 GMT If -bnso is specified on an ld (or cc which does an ld) all libraries will be processed as unshared. Your executable will have bound copies of everything. If you provide a malloc, it will replace the libc malloc. Marc Auslander Hope this helps. >Frank Irwin | "I'll bet $50 on that flush." jim/jsalter IBM PSP, Palo Alto T465/(415)855-4427 VNET: JSALTER at AUSVMQ Internet: jsalter@slo.awdpa.ibm.com UUCP: ..!uunet!ibmsupt!jsalter PS/2 it, or DIE! :-) The ramblings above have nothing to do with Big Blue.