Project

General

Profile

Bug #4383

libelf can't write extended sections when ELF_F_LAYOUT

Added by Richard PALO over 5 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
tools - gate/build tools
Start date:
2013-12-06
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:

Description

/usr/bin/strip coredumps with Assertion failed: (uintptr_t)dst.d_buf < ((uintptr_t)image + outsz), file ../common/update.c, line 670, function wrt32

apparently already discovered as a related problem by richlowe (https://sourceware.org/bugzilla/show_bug.cgi?id=15835)

building thunderbird 24.1.1 on pkgsrc (i386) using gcc 4.8.2 with Solaris Link Editors: 5.11-1.1745 (illumos)
(on a hipster based oi machine).

I get a greadelf message after a huge link (libxul.so) to the tune of :

readelf: Error: File contains multiple symtab shndx tables
readelf: Error: File contains multiple symtab shndx tables

Then later, when building nodebug, /usr/bin/strip fails with the following (recreated here):

$ strip libxul.so
Assertion failed: (uintptr_t)dst.d_buf < ((uintptr_t)image + outsz), file ../common/update.c, line 670, function wrt32
Abort (core dumped)

If I use gstrip, I get the assertion, but it doesn't core (luckily):

$ gstrip libxul.so
BFD: BFD (GNU Binutils) 2.23.1 assertion fail /data/jenkins/jobs/oi-userland/workspace/components/binutils/binutils-2.23.1/bfd/elf.c:1734
BFD: BFD (GNU Binutils) 2.23.1 assertion fail /data/jenkins/jobs/oi-userland/workspace/components/binutils/binutils-2.23.1/bfd/elf.c:1734

I can provide a bzipped libxul.so, if wanted.

History

#1

Updated by Rich Lowe over 5 years ago

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.

#3

Updated by Rich Lowe over 5 years ago

  • Assignee set to Rich Lowe
  • Tags deleted (needs-triage)

I would suspect (though haven't tried), that patching ffunction-sections/-fdata-sections out of the firefox build - again -- would pacify this. libxul.so is comically huge, and has comical amounts of sections. This has caused us problems before, and it's not unreasonable to guess it is now.

I'll look into this further when I get a moment or two.

#4

Updated by Rich Lowe over 5 years ago

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)

#5

Updated by Rich Lowe over 5 years ago

  • Category set to tools - gate/build tools
  • Status changed from New to In Progress
  • % Done changed from 0 to 50

The first problem is, as above, that the user layout doesn't count sections correctly, and doesn't allocate enough space for the header table (this is why we assert).

Secondarily, we don't pass the need for extended sections through into the output ELF header, or update the output extended header with the section count.

Thirdly, we don't preserve the input extended section header (so we lose the string table, etc).

#6

Updated by Rich Lowe over 5 years ago

  • Subject changed from /usr/bin/strip coredumps with Assertion failed: (uintptr_t)dst.d_buf < ((uintptr_t)image + outsz), file ../common/update.c, line 670, function wrt32 to libelf can't write extended sections when ELF_F_LAYOUT
  • % Done changed from 50 to 90
#7

Updated by Richard PALO over 5 years ago

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      

Using versioning, I'm sure I'm dreaming that this would be synchronised with Oracle, so I imagine an illumos-specific tag will probably need to be added, somewhat like what you did with /usr/bin/ld.
Or perhaps a quick and dirty (not libxul!) 'configure' friendly type use case..

#8

Updated by Richard PALO over 5 years ago

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.

#9

Updated by Richard PALO over 5 years ago

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
$
#10

Updated by Rich Lowe over 5 years ago

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)

#11

Updated by Richard PALO over 5 years ago

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.

#12

Updated by Rich Lowe over 5 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

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

#13

Updated by Richard PALO over 5 years ago

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?

#14

Updated by Rich Lowe over 5 years ago

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

Also available in: Atom PDF