This is an archive of the discontinued LLVM Phabricator instance.

Fix Itanium ABI for ARM
Needs ReviewPublic

Authored by weimingz on Nov 21 2014, 4:51 PM.
This revision needs review, but all specified reviewers are disabled or inactive.

Details

Reviewers
espindola
Summary

r218141 "In the Itanium ABI, move stuff to the comdat of variables with static init." causes gnu as crash for ARM in some cases:

foo.s: Assembler messages:
foo.s:208: Internal error!
Assertion failure in get_line_subseg at crosstool_linaro/src/crosstool-ng-linaro-1.13.1-4.8-2014.01/builds/arm-linux-gnueabi-linux/.build/src/binutils-linaro-2.24-2013.12/gas/dwarf2dbg.c line 271.

r218141 handles the comdat of varialbes for Itanium ABI. However, the routine is shared by both ARM and Itanium.
It seems the change should be guarded to Itanium only.

Diff Detail

Event Timeline

weimingz updated this revision to Diff 16519.Nov 21 2014, 4:51 PM
weimingz retitled this revision from to Fix Itanium ABI for ARM.
weimingz updated this object.
weimingz edited the test plan for this revision. (Show Details)
weimingz added a reviewer: rafael.
weimingz added a subscriber: Unknown Object (MLST).

Hi Weiming,

This doesn't look like it's actually implementing either the Itanium or ARM C++ ABI rules. Both specify that the guard variable should be in a COMDAT, they just disagree slightly about the details.

Cheers.

Tim.

Hi Tim,

I'm not sure if it's clang issue or GNU as issue.
I uploaded test cases in http://llvm.org/bugs/show_bug.cgi?id=21644
The generated asms w/ and w/o this patch are also attached.

Please help to take a look.

I see no evidence that this is an LLVM issue. Certainly all Itanium ELF ABIs require the guard variable to be in *some* comdat, and the ARM difference (section 3.2.6 of the C++ ABI) only applies to some fairly obscure linking situations[*] -- not during assembly.

Unfortunately I can't reproduce the issue with my version of as though (only 2.23) so I don't know what's going wrong there. Actually, I probably wouldn't anyway. If it's crashing GNU as, you need a GNU as developer to find out why.

Perhaps they'll come back with a real problem in what we emit, but I don't think it's this.

Cheers.

Tim.

  • Though we do seem to get it wrong for those situations: the guard variable apparently shouldn't be weak.
espindola edited reviewers, added: espindola; removed: rafael.Mar 15 2018, 11:03 AM
aprantl removed a subscriber: aprantl.Mar 15 2018, 11:04 AM