Bug #3299
closedfile should only care about object capabilities
100%
Description
At present, file(1) displays all capabilities in a .SUNW_cap section. This is wrong. Capabilities groups after the first represent symbol capabilities, and aren't interesting to file(1) which displays "... any software or hardware capability requirements"
symbol capabilities don't represent requirements, but a set of alternate implementations selected based on present capabilities.
The most obvious view of this is libsoftcrypto, which contains an SSE2 implementation of certain math, but does not require SSE2
% elfdump -H /usr/lib/libsoftcrypto.so.1 Capabilities Section: .SUNW_cap Symbol Capabilities: index tag value [1] CA_SUNW_ID i386_hwcap1 [2] CA_SUNW_HW_1 0x1040 [ SSE2 MMX ] Symbols: index value size type bind oth ver shndx name [1] 0x0001048e 0x00000490 FUNC LOCL D 0 .text big_ext_gcd_pos%i386_hwcap1 [2] 0x0000e11c 0x0000011b FUNC LOCL D 0 .text bignum2bytestring%i386_hwcap1 [3] 0x00011c18 0x0000003d FUNC LOCL D 0 .text big_modexp_crt%i386_hwcap1 ...
This should not reflected by file(1), but...
% file /usr/lib/libsoftcrypto.so.1 /usr/lib/libsoftcrypto.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE2 MMX], dynamically linked, not stripped, no debugging information available
The capabilities present between brackets should not be listed, as we see from elfdump, above, there are no object capabilities in libsoftcrypto, only symbol capabilities.
Updated by Rich Lowe over 9 years ago
It also turns out that if an object has both symbol and object capabilities, this same issue causes file(1) to display the symcaps and not the object capabilities. Making the output both wrong and incorrect (if you see what I mean).
Updated by Rich Lowe over 9 years ago
- Status changed from In Progress to Resolved
- % Done changed from 50 to 100
Resolved in 3d6a6d0