illumos gate

The objects GNU strip produces will be invalid.

It'd be nice to have the libxul which (our) strip fails on, but if it has already been processed and written by something using GNU libbfd, it will probably be corrupt also.

http://www.netbsd.org/~richard/libxul.so.bz2

The problem is, indeed, yet more Extended ELF section stuff.

strip(1) sets the flag ELF_F_LAYOUT, which means "I know how to layout the file, do what I say"., because of this we use _elf_upd_usr, which does not correct handle extended sections in the least (it will actually mis-count sections entirely)

While I'm testing, I ask the question is it possible to update libelf in such a way as to be able to programatically detect that the strip installed has the fix?

Currently:

$ /usr/bin/strip -V
/usr/bin/strip: Software Generation Utilities (SGU) Solaris-ELF (4.0)
$ elfdump -v /usr/lib/libelf.so

Section Définition de version :  .SUNW_version
     index  version                     dépendance
       [1]  libelf.so.1                                      [ BASE ]
       [2]  SUNW_1.7                    SUNW_1.6             
       [3]  SUNW_1.6                    SUNW_1.5             
       [4]  SUNW_1.5                    SUNW_1.4             
       [5]  SUNW_1.4                    SUNW_1.3             
       [6]  SUNW_1.3                    SUNW_1.2             
       [7]  SUNW_1.2                    SUNW_1.1             
       [8]  SUNW_1.1                    SUNW_0.7             
       [9]  SUNW_0.7                                         
      [10]  SUNWprivate_1.1                                  

Section Version requise :  .SUNW_version
     index  file                        version
      [11]  libc.so.1                   SUNW_1.23            
      [12]                              SUNW_1.1             [ INFO ]
      [13]                              SUNW_0.8             [ INFO ]
      [14]                              SUNW_0.7             [ INFO ]
      [15]                              SYSVABI_1.3          [ INFO ]
      [16]                              SUNWprivate_1.1      

As expected, this seems to work now on this program build.

BTW, as for binutils, any word or possibility to get that fixed as well?

richard@x3200:~/src/tb24$ greadelf -I libxul.so
readelf: Error: File contains multiple symtab shndx tables
readelf: Error: File contains multiple symtab shndx tables

Histogram for bucket list length (total of 4871 buckets):
 Length  Number     % of total  Coverage
      0  1746       ( 35.8%)
      1  1846       ( 37.9%)     37.9%
      2  908        ( 18.6%)     75.2%
      3  287        (  5.9%)     92.9%
      4  73         (  1.5%)     98.9%
      5  11         (  0.2%)    100.0%

In the meanwhile, I'll prepare another report for a different problem involving binutils on a differentlarge solaris ld object.

Thanks for your prompt response.

adding ILLUMOS_0.1 to libelf.so would be great, such as what has been done with libc.so...

$ elfdump -v /lib/libc.so |grep ILLUMOS
       [2]  ILLUMOS_0.7                 ILLUMOS_0.6          
       [3]  ILLUMOS_0.6                 ILLUMOS_0.5          
       [4]  ILLUMOS_0.5                 ILLUMOS_0.4          
       [5]  ILLUMOS_0.4                 ILLUMOS_0.3          
       [6]  ILLUMOS_0.3                 ILLUMOS_0.2          
       [7]  ILLUMOS_0.2                 ILLUMOS_0.1          
       [8]  ILLUMOS_0.1                 SUNW_1.23            
$ elfdump -v /lib/libelf.so |grep ILLUMOS
$

Library versions version specific symbols -- we haven't added any to libelf, so we can't do that.

I'm nervous of updating the version information provided by tools other than the link-editor, because it has to my knowledge never ever been done (the 4.0 you see is the 4 in SVr4). If you were wanting to detect this fix, I'd probably just adjust my Makefile or script so that the exit status of strip(1) was ignored -- prior to this bug, we'd crash before writing the file so while we wouldn't strip, we wouldn't damage the file either.

That said, it's actually likely that I should bump the version of ld(1) here, since it does affect ld as well, so you could also do that (when I've adjusted the code so I do)

Currently, the hack already implemented is to set (in pkgsrc) INSTALL_UNSTRIPPED=yes.

I'd like to put this in a guard statement. I guess checking a version of ld(1) would be okay as long as it is deterministic.

Thanks.

Rich Lowe wrote:

Resolved in deec6be (which will have bumped the version of ld(1))

Rich, maybe I miss something in the commit, but where exactly is the version of ld actually bumped?

The version of ld is derived from the contents of SUNWonld-README via usr/src/cmd/sgs/packages/common/readme_revision, it'll be 1.1748