On Wed, 24 Oct 2018, Rainer Orth wrote: > Hi Eric, > > >> I know: a patch to fix this is almost ready, just needs a final round of > >> testing. > > > > OK, thanks for the information. > > here's what I've got. It took me two false starts, unfortunately: > > * Initially, I just tried linking with LD_OPTIONS='-z nocompstrtab': > > -z nocompstrtab > > Disables the compression of ELF string tables, and comment sec- > tions. By default, string compression is applied to SHT_STRTAB sec- > tions, to SHT_PROGBITS sections that have their SHF_MERGE and > SHF_STRINGS section flags set, and to comment sections. > > While that worked, this approach has several disadvantages: if the > objects are somehow linked without that option, the resulting > executables will suddenly and mysteriously start to die with SIGBUS. > It would be far better if the objects themselves are save to use in > whatever way without relying on a special non-default linker option. > Besides, it also disable string table compression, so has a far larger > impact than necessary. > > * Next, I tried to disable HAVE_GAS_SHF_MERGE completely before Solaris > 11.4. This also fixed the regressions you observed. Unfortunately, > while this is what's used with as/ld since the Solaris assembler > doesn't fully support setting SHF_MERGE/SHF_STRINGS yet, when gas is > in use, hundreds of Go test start to FAIL on both sparc and x86: > > runtime stack: > fatal error: DW_FORM_strp out of range in .debug_info at 166762 > panic during panic > > The error is from libbacktrace/dwarf.c (read_attribute) which is > linked into libgo.so.13. While readelf --debug-dump=info shows no > problem, dwarfdump -a complains loudly. > > I haven't yet investigated what exactly is happening here. > > * Instead I tried an approach that one of the Solaris linker engineers > suggested which both avoids the need for special linker options and a > large part of the impact: it just disables string merging for sections > with alignment > 1 with older (pre-Solaris 11.4) versions of Solaris > ld. This one worked just fine and seems the preferred approach. > While the Solaris 10/SPARC ld didn't show the regressions seen on > 11.3, I've decided to apply the workaround there, too, to avoid > running into problems if those objects are later relinked on Solaris 11. > > Bootstrapped without regressions on i386-pc-solaris2.1[01] and > sparc-sun-solaris2.1[01] (both Solaris 11.3 and 11.4 each) with as/ld, > gas/ld, and x86_64-pc-linux-gnu. > > Ok for mainline?
LGTM. Richard.
