Project

General

Profile

Bug #5595

libzpool won't build with a studio primary

Added by Rich Lowe about 5 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
zfs - Zettabyte File System
Start date:
2015-02-05
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:

Description

Since ZFS started putting inline functions in headers, libzpool has been unable to build with Sun Studio.

The reason is that Sun Studio creates COMDAT GROUP sections for the out-of-line version of these symbols, but in doing so creates invalid groups which refer to non-existent sections:

Group Section:  .group%zap_m_phys
     index    flags / section         signature symbol
       [0]   [ COMDAT ]               zap_m_phys
       [1]   .text%zap_m_phys [6]
       [2]   <invalid section> [20]
       [3]   <invalid section> [21]

ld(1), quite rightly (in my view) considers this group invalid, and its presence a fatal error

ld: fatal: file pics/zap_micro.o: group section [2].group%zap_m_phys: entry 2: invalid section index: 20
ld: fatal: file pics/zap_micro.o: section [6].text%zap_m_phys: SHF_GROUP flag set, but no corresponding SHT_GROUP section found

There is nothing I can do about this except make ld(1) more forgiving of invalid groups where in this case "forgiving" is, perhaps, a way of saying "wrong". I would rather not do this.

Clearly, though, we also can't fix Sun Studio.

The other option is ZFS ceasing to use inline functions in headers like this, or doing so in a way which (portably) never emits an out-of-line definition.


Related issues

Has duplicate illumos gate - Bug #5580: Sun Studio probably relies on the behaviour 3616 removedRejected2015-01-31

Actions

History

#1

Updated by Rich Lowe about 5 years ago

What's happening is not Studio emitting invalid groups. What happens is that Studio emits a group that contains 3 sections, the .text, and the .stabs for the out-of-line functions.

ctfconvert then comes along and deletes the stabs sections as it runs, but never updates the group. This means the group is now trash.

ctfconvert needs to fix all this up. ld(1) is certainly working fine.

#2

Updated by Rich Lowe about 5 years ago

  • Status changed from New to In Progress
  • Assignee set to Rich Lowe
  • % Done changed from 0 to 80
#3

Updated by Gordon Ross about 5 years ago

Generally, inline functions in headers are intended to be used only as inlines.
As long as that's true here, convincing the compiler to not create the external version of the inline seems best.
What's the best (portable) way to do that?

#4

Updated by Rich Lowe about 5 years ago

I'm fixing ctfconvert (and ctfmerge) because they're unquestionably broken.

#5

Updated by Gary Mills about 5 years ago

The Studio compiler has these options:

     -features=[a]
          The compiler's treatment of extern inline functions
          conforms by default to the behavior specified by the
          ISO/IEC 9899:1999 C standard. Compile new codes with
          -features=no%extinl to obtain the same treatment of
          extern inline functions as provided by versions 5.5, or
          older, of the C and C++ compilers.

          If you do not specify a flag for -features, the com-
          piler sets it to -features=extinl.

          extinl         Generates extern inline functions as
                         global functions. This is the default,
                         which conforms with the 1999 C standard.

          [no%]extinl    Generates extern inline functions as
                         static functions.
#6

Updated by Electric Monk about 5 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 80 to 100

git commit 495021bdf7d49b2cc9a6e6981b5ec4110264741b

commit  495021bdf7d49b2cc9a6e6981b5ec4110264741b
Author: Richard Lowe <richlowe@richlowe.net>
Date:   2015-02-26T19:19:39.000Z

    5595 libzpool won't build with a studio primary
    Reviewed by: Josef 'Jeff' Sipek <josef.sipek@nexenta.com>
    Reviewed by: Robert Mustacchi <rm@joyent.com>
    Approved by: Gordon Ross <gwr@nexenta.com>

#7

Updated by Electric Monk about 5 years ago

git commit c79a74a8321729c8f50472db67e907324bace4e5

commit  c79a74a8321729c8f50472db67e907324bace4e5
Author: Richard Lowe <richlowe@richlowe.net>
Date:   2015-03-09T21:15:17.000Z

    5595 libzpool won't build with a studio primary (fix usage message)

Also available in: Atom PDF