Software source in shell archives. Shift click to download. The binary applications are only usable on Silicon Graphics machines running IRIX6.* All of these are little hacks I wrote for my own use (well 'shar' is freeware I find useful, not something I wrote, but you get the idea).
Use SHIFT-leftmouse to download what appeals to you.
loan schedule printout loan.shar (9Kbytes)
loan schedule (source)
(10KBytes)
loan schedule (binary)
(26KBytes)
---
ldd
ldd is a utility that shows the DSOs used by an
executable (or a DSO) at run time.
It shows the full tree (unlike elfdump -Dl, which
just shows the DSOs listed in the one liblist) and it shows
the actual path chosen at run time using
any rld-related environment variables which
are set (unlike elfdump -Dl, which
knows no run-time path information).
---
While there is an official ldd that will be in some future
IRIX release, this perl 5 script
Perl script implementing ldd
is quite sufficient for most folks.
For a version that intercepts a running program and
prints the DSOs that application is using, see trace-objlist
---
trace-objlist
trace-objlist is a utility that shows the DSOs in use
by a running application.
You provide the process id or the name of the executable.
It shows the full list (unlike elfdump -Dl, which
just shows the DSOs listed in the one liblist) and it shows
the actual path chosen at run time by the run time linker.
c source in a shell archive
For a version that works on the disk image of
an executable, see pldd above.
Currently, this only supports n32 ABI processes
(call me lazy).
---
display ELF object file (readobj).
I find the format of elfdump -o and elfdump -h to not
be entirely to my liking, so I wrote this utility.
It also understands the basics of the old 32bit ABI
so it prints the header information about the debug
information format (now called mdebug) in
an old 32bit ABI object.
object file dumper (source) (105KBytes)
object file dumper (binary) (109KBytes)
---
display IRIX core file.
While the 'file' command says what a core file came from,
this looks a bit more deeply into the IRIX core file data,
which has a format different from other machines, even
other UN*X machines.
Updated July 14, 1999.
core file dumper (source) (8KBytes)
core file dumper (binary) (62KBytes)
---
hex dump program
this is hex dumper dumping any file in hexadecimal in
a style reminiscent of certain mainframe hex dumps.
hex dumper (source) (5KBytes)
hex dumper (binary) (27KBytes)
---
Program displaying its own dso list.
(an example of doing something most applications
never need to do!)
dsolist display (source) (7KBytes)
---
Program displaying its own memory regions list using
PIOCMAP PIOCNMAP.
(an example of doing something most applications
never need to do!)
memory regions lister (source) (6KBytes)
---
Program to patch a binary (to patch any file, really)
binary patch (source) (10KBytes)
binary patch (binary) (40KBytes)
---
find file offset of virtual address in elf object
This is most useful to find the location, on disk,
of something whose virtual address you know.
One might use nm(1) to find a virtual address,
fileoff (this perl script) to find the file offset,
hxdump to see what is there, and binpatch to 'fix'
the binary.
The perl5 script uses elfdump(1), which is the IRIX name
of the object dumping utility, and relies
on the specfic -o and -h formatting done by elfdump.
(should be a simple task to parse Linux (gnu) objdump output,
but I have not tested that).
SHIFT-leftmouse to download perl5 script
---
print archive-internal header information
This is most useful to understand what, exactly,
is in an archive.
It shows the gritty details of the archive header records.
SHIFT-leftmouse to download shell archive of C source
---
shell archive creator
shar is a freeware program written in C by Gary Perlman/Wang
Institute which turns a collection of source files into a shell
archive for easy mailing or downloading. The source code has a
short bit of history on shell archives: the original was a shell
script by James Gosling at CMU posted in 1982 (see shar.c for
details).
make shell archive (source) (23Kbytes)
make shell archive (binary) (24KBytes)
---
Speeding up startup of apps with many DSOs
For folks building many DSOs (shared libraries) that all link together (say close to 100 DSOs) it may be true that some symbols can be 'hidden' and that that will speed up application load time. It can only help if one builds (and can thus safely rebuild) many DSOs. System DSOs and DSOs one does not build oneself don't count. If the DSOs are built entirely or substantially with C++, there can be many hidable symbols.
While this note does not discuss -Bsymbolic (an ld option) you should also try -Bsymbolic in your DSO creation, as that can (for an app with a large number of DSOs) have the effect of dramatically reducing startup time. -Bsymbolic makes 'preemption' impossible ('man dso' for more info) but for most developer-created DSOs preemption of its symbols is never used anyway. Using -Bsymbolic and hiding all possible symbols in creating a given DSO is a good idea too. C++ symbols relating to RTTI (run time type information) must not be hidden.
You will want to pick up commentary and shell scripts to understand the details (in a shell archive). Last updated June 30, 2000.
Second, pick up the optionalsym program (33025 bytes) (source in a shell archive) as one part of verifying that the approach actually saves time.