Date: Tue, 09 Jan 1996 21:31:53 -0800 From: John Polstra <jdp@polstra.com> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: dfr@render.com, freebsd-hackers@freebsd.org Subject: Re: Anyone got GNU `dld' ported to FreeBSD? Message-ID: <199601100531.VAA17720@austin.polstra.com> In-Reply-To: Your message of "Tue, 09 Jan 1996 21:06:47 PST." <3075.821250407@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > executable dynamically-linked. You can get around this if you're
> > willing to have your executable "depend" on a tiny do-nothing shared
> > library. First create a file "tiny.c" that contains this:
>
> Whaddya know. It works!
>
> Now is there any chance of getting:
>
> > void a_real_kludge() { }
>
> Down below 8K? :-)
I've been just _waiting_ for that one ;-). How about 4208 bytes?
The reason it's 8K is because there a text segment and a data segment,
and each is rounded up to a multiple of the page size. That's dictated
by the way the library is mmapped into memory. (Even though tiny.o
doesn't have any data, there's still some required for the dynamic
linking stuff such as the PLT and the GOT.)
But, OK, fasten your seatbelt and put the kludgeometer pedal to the
metal:
austin$ dd bs=4208 count=1 <libtiny.so.1.0 >newlibtiny.so.1.0
austin$ mv newlibtiny.so.1.0 libtiny.so.1.0
austin$ ls -l libtiny.so.1.0
-rw-r--r-- 1 jdp jdp 4208 Jan 9 21:13 libtiny.so.1.0
austin$ ldd a.out
a.out:
libtiny.so.1.0 => libtiny.so.1.0 (0x8025000)
austin$ ./a.out
Hello, world!
I suppose I'd better explain where the magic number 4208 came from. The
data segment occupies the second page of the file. (There is no bss in
libtiny.) But most of it is unused. The easiest way to find out how
much is unused is to do this (using the old, 8K libtiny again):
austin$ hexdump libtiny.so.1.0-
0000000 00cc c086 1000 0000 1000 0000 0000 0000
0000010 0000 0000 0020 0000 0000 0000 0000 0000
0000020 8955 c9e5 00c3 0000 0000 0000 0000 0000
0000030 0002 0000 0005 0000 0000 0000 0004 0000
0000040 ffff ffff 0000 0000 0001 0000 0000 0000
0000050 0003 0000 0000 0000 0004 0000 0000 0000
0000060 0000 0000 0007 0000 1000 0000 0000 0000
0000070 000a 0000 0205 0000 0020 0000 0000 0000
0000080 0019 0000 0005 0000 00dc 0000 0000 0000
0000090 0020 0000 0007 0000 106c 0000 0000 0000
00000a0 0027 0000 0009 0000 106c 0000 0000 0000
00000b0 5f5f 5944 414e 494d 0043 615f 725f 6165
00000c0 5f6c 6c6b 6475 6567 5f00 7465 7865 0074
00000d0 655f 6164 6174 5f00 6e65 0064 0000 0000
00000e0 0000 0000 0000 0000 0000 0000 0000 0000
*
0001000 0008 0000 1010 0000 1028 0000 0000 0000
0001010 0000 0000 0000 0000 0000 0000 0000 0000
*
0001030 0000 0000 1060 0000 1064 0000 0030 0000
0001040 0030 0000 0060 0000 0000 0000 0004 0000
0001050 00b0 0000 002c 0000 1000 0000 0008 0000
0001060 1000 0000 e990 fffa ffff 0000 0000 0000
0001070 0000 0000 0000 0000 0000 0000 0000 0000
*
0002000
So everything from byte 0x1070 (= 4208) to the end is just zero-fill,
and can be thrown away. The mmap call will still map the whole page; it
doesn't care if there's no file data behind some of it.
> I know, I know, I want everything.. :)
That's what you're there for. That's what keeps us going.
-- John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601100531.VAA17720>