[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 --- Comment #47 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #46) > Is this fixed for 9+ so far? Yes, fixed on trunk .. leaving it open pending backports.
[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 --- Comment #46 from Jakub Jelinek --- Is this fixed for 9+ so far?
[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 --- Comment #45 from Iain Sandoe --- Author: iains Date: Wed Aug 22 11:37:02 2018 New Revision: 263763 URL: https://gcc.gnu.org/viewcvs?rev=263763=gcc=rev Log: Fix FDE labels for Darwin gcc/ PR bootstrap/81033 PR target/81733 PR target/52795 * gcc/dwarf2out.c (FUNC_SECOND_SECT_LABEL): New. (dwarf2out_switch_text_section): Generate a local label for the second function sub-section and apply it as the second FDE start label. * gcc/final.c (final_scan_insn_1): Emit second FDE label after the second sub-section start. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/final.c
[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 --- Comment #44 from Iain Sandoe --- (In reply to Eric Gallager from comment #43) > (In reply to Iain Sandoe from comment #42) > > (In reply to Elliot Saba from comment #41) > > > Has there been any progress on this? We are running into this while > > > trying > > > to cross-compile GCC for Darwin. Has this been fixed in 8.3.0? > > > > I will be posting two patches (one just posted today) that are my proposed > > solution - basically, v2 above plus removing a target hook. > > One is here: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00798.html (this one still needs review from someone for the dwarf2out / final) the other was https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00767.html (approved and applied, will be backported soon)
[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 Eric Gallager changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-08/msg00798.ht ||ml --- Comment #43 from Eric Gallager --- (In reply to Iain Sandoe from comment #42) > (In reply to Elliot Saba from comment #41) > > Has there been any progress on this? We are running into this while trying > > to cross-compile GCC for Darwin. Has this been fixed in 8.3.0? > > I will be posting two patches (one just posted today) that are my proposed > solution - basically, v2 above plus removing a target hook. One is here: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00798.html
[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 --- Comment #42 from Iain Sandoe --- (In reply to Elliot Saba from comment #41) > Has there been any progress on this? We are running into this while trying > to cross-compile GCC for Darwin. Has this been fixed in 8.3.0? I will be posting two patches (one just posted today) that are my proposed solution - basically, v2 above plus removing a target hook.
[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 Elliot Saba changed: What|Removed |Added CC||staticfloat at gmail dot com --- Comment #41 from Elliot Saba --- Has there been any progress on this? We are running into this while trying to cross-compile GCC for Darwin. Has this been fixed in 8.3.0?
[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 Iain Sandoe changed: What|Removed |Added Attachment #6|0 |1 is obsolete|| Attachment #7|0 |1 is obsolete|| --- Comment #40 from Iain Sandoe --- Created attachment 44452 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44452=edit Version 2, create a new label instead of attempting to re-use Trying to re-use the existing cold start labels causes regressions in some targets when the ordering of sections is affected. I'm testing the attached version across a variety of platforms (it's OK on x86-64 Darwin and Linux so far). What this does is to create a new label (in a similar vein to the LFBn label that's generated for the first FDE).
[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 Iain Sandoe changed: What|Removed |Added CC||jeremyhu at macports dot org --- Comment #39 from Iain Sandoe --- *** Bug 82092 has been marked as a duplicate of this bug. ***
[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 --- Comment #38 from Iain Sandoe --- Created attachment 7 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=7=edit fix for 8.2 same discussion, patch on 262993 (8.2 release rev.)
[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 --- Comment #37 from Iain Sandoe --- Created attachment 6 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=6=edit Proposed fix for trunk Subject: [PATCH] Fix P81033 for FDEs in partitioned code. Darwin has the ability to split code into "atoms" in the static linker. These can then be re-ordered to optimise the code layout (this is a more fine-grained equivalent of function-sections). This facility requires cooperation of the compiler, assembler and linker. As the assembly stage it's signalled by marking objects as "subsections_vis_symbols" the (expected) default. The rules for splitting code into atoms (if applied strictly) are like this: _linker_visible_labelA: << starts Atom A (section start if there's no linker visible label before the first local one) ... LocalLabelA: <<== belongs to Atom A ... LocalLableB: <<== belongs to Atom A ... LocalLabelC: <<== belongs to Atom A **Even if it has the same address as _linker_visible_labelB** _linker_visible_labelB: << starts Atom B LocalLabelD: <<== belongs to Atom B = There are two assemblers in common use for Darwin; one based on an old GAS version (so-called cctools) and one based on the LLVM toolchain. Newer vendor toolchains are based by default on the LLVM toolchain, and older ones on the cctools. The cctools assembler is strict about the atom definitions, the LLVM- based one is apparently more relaxed. The particular issue that affects the FDE generation in partitioned code is this: (section start, or linker-visible symbol makes no difference) LcoldStartN: (generally 0-length) _functionN_cold.0: << needed to identify the start of a new atom, << and also to assist in debug on many platforms. . then we have in the eh_frame section: ... .quad LcoldStartN - . .long LColdEndN - LcoldStartN Which is intended to point to the start of the code (comes after _functionN_cold.0) But with the cctools assembler, that's not what "LcoldStartN" means, and thus it ends up (usually) pointing to the section start - or worse, to some random place in a previous function). With the LLVM-based toolchain, the assembler appears to allow for the case that LcoldStartN == _functionN_cold.0. BUT (a) it's not guaranteed that this _is_ the case since alignment of _functionN_cold.0 might put nops between LcoldStartN and _functionN_cold.0. (b) It is probably intended to support aliasing and is not intended to change the atom ABI. ** I suppose it’s exploiting a slight ambiguity as to how to approach a zero-sized atom. However, according to the strict def. the local label should be made to exist in a distinct atom - even if that has zero size (and can be laid out wherever we like). So .. - For FDEs, the solution is to place LcoldStartN: _after_ _functionN_cold.0 JFTR, one cannot do things like .quad _functionN_cold.0 - . .long LColdEndN - _functionN_cold.0 (i.e. replace the local symbol for the cold section in the FDE by the actual linker-visible one) .. since that produces the case that the second expression cannot be resolved at assembly time and it fails. = So this is the simplest patch to ensure that the cold sub-section local symbol appears after the linker-visible one. It moves the output of the symbol from assemble_function_start to the point at which the switch occurs. NOTE that this problem has already been resolved for the first function subsection, since the function start label _myfunction: is followed by LFBN: <<< this is referenced in the first FDE for the function. = Since final.c now emits a linker-visible symbol on the switch the one added to emit from the target hook (on text section switch) is both redundant and confuses the linker by having two co-incident symbols. So the patch removes the implementation of the target hook for text sect switch. --- gcc/config/darwin.c | 15 --- gcc/config/darwin.h | 4 gcc/final.c | 5 + gcc/varasm.c| 4 4 files changed, 5 insertions(+), 23 deletions(-)
[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 Jakub Jelinek changed: What|Removed |Added Target Milestone|8.2 |8.3 --- Comment #36 from Jakub Jelinek --- GCC 8.2 has been released.
[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 Jakub Jelinek changed: What|Removed |Added Target Milestone|8.0 |8.2 --- Comment #35 from Jakub Jelinek --- GCC 8.1 has been released.
