Bug #3210

ld should tolerate SHT_PROGBITS for .eh_frame sections on amd64

Added by Robert Mustacchi about 8 years ago. Updated about 8 years ago.

lib - userland libraries
Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


This is upstreaming

The following is from the original Joyent bug report from Bryan:

Historically, the section containing the logic to unwind stack frames – the .eh_frame section – was of type SHT_PROGBITS. Apparently the most aesthetically galling aspect of this was not the .eh_frame section's dubious purpose or its filthy implementation, but rather its section type; with the introduction of the AMD64 ABI, a new section header type (SHT_AMD64_UNWIND) was introduced for (and dedicated to) this section. When both the Sun compilers and the GNU compilers had been modified to generate this new section type, the linker became much more pedantic about .eh_frame: it refused to link an AMD64 object that contained a .eh_frame with the legacy SHT_PROGBITS. That this was too fussy is evidenced by searching the net for the error message that it generated ("section type is SHT_PROGBITS: expected SHT_AMD64_UNWIND"), which reveals a myriad of problems, including legacy objects, hand-coded assembly and otherwise cross- platform objects created on other platforms (the GNU toolchain was only modified to create the new section type on Solaris and derivatives). It is this last of these that is most problematic for us; several libraries are compiled using a Linux-only compiler (icc) – they need to be able to generate objects on Linux that can run on SmartOS. The fix here is to both allow SHT_PROGBITS for .eh_frame, and to correctly merge such .eh_frame sections with .eh_frame sections of type SHT_AMD64_UNWIND.


Updated by Robert Mustacchi about 8 years ago

  • Status changed from New to Resolved
  • % Done changed from 90 to 100

Resolved in 13830:8a85b2c3d89b.

Also available in: Atom PDF