Peter Memishian wrote:
> I've always wondered...why are shared libraries installed under *NIX
> operating systems with the executable bit set? They seem to work
> regardless of whether the bit is set or not. I'm sure there's
> something I'm missing, but after a few hours of searching I can't seem
> to find why.
an excellent question --
It's historic. Shared objects contain executable code, therefore the
execute bit was appropriate. However, the program header indicates
the text segment should be mapped executable:
ison 1435. elfdump -p /lib/libc.so.1
Program Header[0]:
p_vaddr: 0 p_flags: [ PF_X PF_R ]
p_paddr: 0 p_type: [ PT_LOAD ]
....
and this mapping (on the OS's I know) is sufficient to provide
executable permission.
..... and to add insult to injury, attempting to
execute them is far from pretty:
>
$ /lib/libc.so
usage: ld.so.1 [-e option,...] dynamic-object [object args,...]
Killed
Hmmm, I've not interpreted the "execute bit" to indicate the file
was an "executable", but rather it contained executable code, but ...
More history. The original intel ABI stated the interpretor for
dynamic executables was /usr/lib/libc.so.1. Thus, we established
the entry point of libc to be something special:
ison 1433. elfdump -e /lib/libc.so.1
ELF Header
....
e_entry: 0x1db10 e_ehsize: 52 e_shstrndx: 27
....
ison 1434. elfdump -s /lib/libc.so.1 | fgrep 1db10
[307] 0x0001db10 0x000000a3 FUNC LOCL H 0 .text __rtboot
This __rtboot routine maps in ld.so.1 and jumps to it. Thus we
support libc as an interpretor, but eventually get back to the one
true interpretor, ld.so.1 :-)
And, you can execute ld.so.1 directly:
ison 1436. /usr/lib/ld.so.1 /usr/bin/date
Sun Jul 24 19:34:05 PDT 2005
But, if you don't give ld.so.1 any arguments, you get a usage message:
ison 1437. /usr/lib/ld.so.1
/usr/lib/ld.so.1: /usr/lib/ld.so.1: fatal: usage: ld.so.1 [-e
option,...] <dynamic object> [exec args ...]
Killed
$ /lib/libnsl.so
Illegal Instruction (core dumped)
cc'ing rod, as he will probably know the history here.
When ld(1) creates a dynamic executable or shared object it always
sets the entry point, e_entry. Typically this is main, or _main,
or you can use ld(1) -e to establish an entry point. Without
any of these, e_entry is set to the first byte of the first test
section. Dunno why, just another bit of history.
ison 1439. elfdump -e /lib/libnsl.so.1
ELF Header
....
e_entry: 0x94 e_ehsize: 52 e_shstrndx: 25
....
ison 1440. elfdump -c /lib/libnsl.so.1 | head
Section Header[1]: sh_name: .SUNW_syminfo
sh_addr: 0x94 sh_flags: [ SHF_ALLOC SHF_INFO_LINK ]
....
Hmmm, executing the first byte of the .SUNW_syminfo isn't going to
get you very far - as you've found out.
Funny old world isn't it?
--
Rod
_______________________________________________
opensolaris-code mailing list
[email protected]
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
