On 10/12/10 2:03 AM, Piotr Jasiukajtis wrote:
elfdump -H libapr-0.so.0 says nothing:
# elfdump -H ./libapr-0.so.0 ; echo $?
0
It's a rather unhappy object. elfdump(1) reveals lots of errors
in regards inconsistent symbol tables, and an inconsistent .dynamic
section:
% elfdump -d libapr\-0.so.0.9.17
Dynamic Section: .dynamic
index tag value
[0] NEEDED 0x2847 libsendfile.so.1
....
[14] CHECKSUM 0x4d35
libapr-0.so.0.9.17: object lacks [ SHT_SUNW_verneed ] section required by
DT_VERNEED dynamic entry
[15] VERNEED 0x64f0
[16] VERNEEDNUM 0x8
....
[23] FEATURE_1 0x1 [ PARINIT ]
libapr-0.so.0.9.17: object lacks [ SHT_SUNW_cap ] section required by
DT_SUNW_CAP dynamic entry
[24] SUNW_CAP 0xb4
....
[28] NULL 0
Here, the .dynamic section has recorded the existence of a capabilities
section (SUNW_cap), but there's no .SUNW_cap section in the section header
table. Normally you'd find something like this:
Section Header[1]: sh_name: .SUNW_cap
sh_addr: 0xb4 sh_flags: [ SHF_ALLOC ]
sh_size: 0x10 sh_type: [ SHT_SUNW_cap ]
sh_offset: 0xb4 sh_entsize: 0x8
sh_link: 0 sh_info: 0
sh_addralign: 0x4
Hmm, but perhaps there was a capabilities entry at one point? There's
a program header that suggests such:
Program Header[0]:
p_vaddr: 0 p_flags: [ PF_R ]
p_paddr: 0 p_type: [ PT_SUNWCAP ]
p_filesz: 0 p_memsz: 0
p_offset: 0 p_align: 0x4
And the first section of the file is:
Section Header[1]: sh_name: .hash
sh_addr: 0xc4 sh_flags: [ SHF_ALLOC ]
sh_size: 0x13bc sh_type: [ SHT_HASH ]
sh_offset: 0xc4 sh_entsize: 0x4 (1263 entries)
sh_link: 2 sh_info: 0
sh_addralign: 0x4
Which suggests something might have existed at 0xb4:
% od -x libapr\-0.so.0.9.17 +0xd4 | head
00000d4 0003 0000 0004 0000 0007 0000 0000 0000
The reason ld.so.1 (and hence ldd) is complaining is because the
PT_SUNWCAP indicates the capabilities exist at 0x0, the base address
of the loaded object. Hence ld.so.1/ldd are looking at the ELF
header and trying to determine capabilities. A "fixed" ld.so.1/ldd
would reveal:
./libapr-0.so.0.9.17: unknown capability: 0x464c457f
mcs(1) can sometimes tell you who built the object, but all I see is:
acomp: Sun C 5.8 Patch 121016-02 2006/03/31
as: Sun Compiler Common 11 Patch 120759-08 2006/08/08
I don't see any record from ld(1). You'd normally see something like:
acomp: Sun C 5.9 SunOS_sparc Patch 124867-11 2009/04/30
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.477
So, I don't know if you had a broken ld(1) build this file, a different
link-editor build it, or someone has been doctoring the file after it
was built.
BTW, we filed and have a fix in the works for
6990845 unknown capabilities tags are poorly diagnosed
which corrects the poor "unknown capability: 0" diagnostic are seeing.
But, I can't explain how the object was constructed, so if you have any
clues of the original compilation environment this came from, we might
be able to determine what's gone wrong.
--
Rod
_______________________________________________
tools-linking mailing list
[email protected]
