Re: [PATCH][PR debug/60655] Power/GCC: Reject cross-section symbol subtraction
On Wed, Sep 03, 2014 at 03:01:17PM +0930, Alan Modra wrote: In fact if you look at the corresponding location expression for -fno-section-anchors code you get something quite screwy too. 018f 0108 0114 (DW_OP_breg10 (r10): 0; DW_OP_addr: 144; DW_OP_plus; DW_OP_stack_value which is (r10) + modulus. Fixed with this obvious patch. Emitting part of a .debug_loc expression is worse than no expression. Bootstrapped and regression tested x86_64-linux and committed revision 214899. PR debug/60655 * dwarf2out.c (mem_loc_descriptor PLUS): Return NULL if addend can't be output. Index: gcc/dwarf2out.c === --- gcc/dwarf2out.c (revision 214898) +++ gcc/dwarf2out.c (working copy) @@ -12699,7 +12699,7 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mod op1 = mem_loc_descriptor (XEXP (rtl, 1), mode, mem_mode, VAR_INIT_STATUS_INITIALIZED); if (op1 == 0) - break; + return NULL; add_loc_descr (mem_loc_result, op1); add_loc_descr (mem_loc_result, new_loc_descr (DW_OP_plus, 0, 0)); -- Alan Modra Australia Development Lab, IBM
Re: [PATCH][PR debug/60655] Power/GCC: Reject cross-section symbol subtraction
On Thu, 4 Sep 2014, Alan Modra wrote: In fact if you look at the corresponding location expression for -fno-section-anchors code you get something quite screwy too. 018f 0108 0114 (DW_OP_breg10 (r10): 0; DW_OP_addr: 144; DW_OP_plus; DW_OP_stack_value which is (r10) + modulus. Fixed with this obvious patch. Emitting part of a .debug_loc expression is worse than no expression. Bootstrapped and regression tested x86_64-linux and committed revision 214899. PR debug/60655 * dwarf2out.c (mem_loc_descriptor PLUS): Return NULL if addend can't be output. Thanks for your analysis and the fix, unfortunately the test case still fails here, so it must be something else yet. :( Maciej
Re: [PATCH][PR debug/60655] Power/GCC: Reject cross-section symbol subtraction
On Thu, Sep 04, 2014 at 10:05:38PM +0100, Maciej W. Rozycki wrote: On Thu, 4 Sep 2014, Alan Modra wrote: In fact if you look at the corresponding location expression for -fno-section-anchors code you get something quite screwy too. 018f 0108 0114 (DW_OP_breg10 (r10): 0; DW_OP_addr: 144; DW_OP_plus; DW_OP_stack_value which is (r10) + modulus. Fixed with this obvious patch. Emitting part of a .debug_loc expression is worse than no expression. Bootstrapped and regression tested x86_64-linux and committed revision 214899. PR debug/60655 * dwarf2out.c (mem_loc_descriptor PLUS): Return NULL if addend can't be output. Thanks for your analysis and the fix, unfortunately the test case still fails here, so it must be something else yet. :( Yes, my patch wasn't supposed to fix the testcase, just ensure that we don't get partial (and thus wrong) expressions emitted when const_ok_for_output rejects part of a location description. Jakub's 2014-04-04 patch rejected NOT, which is what we happen to hit for -fno-section-anchors. Your patch rejects the problematic MINUS case seen with -fsection-anchors, and prior to my mem_loc_descriptor fix, left us with bogus debug info. That bogus debug info was my main objection to your patch going onto trunk. Since that is now fixed and rejecting the MINUS is no worse than rejecting NOT, I withdraw that objection. Of course it would be better to repair the damage done to debug info rather than rejecting it outright.. -- Alan Modra Australia Development Lab, IBM
[PATCH][PR debug/60655] Power/GCC: Reject cross-section symbol subtraction
Hi,
Similarly to ARM, where this issue was seen originally, and likely many
other targets, the Power ABI does not appear to have a relocation defined
to support taking a difference of two symbols in different sections each.
This is seen as a failure in gcc.c-torture/compile/pr60655-2.c:
Executing on host: powerpc-linux-gnu-gcc -fno-diagnostics-show-caret
-fdiagnostics-color=never -O3 -g -w -c -o pr60655-2.o
.../gcc/testsuite/gcc.c-torture/compile/pr60655-2.c(timeout = 300)
/tmp/ccAfNLMj.s: Assembler messages:
/tmp/ccAfNLMj.s:932: Error: can't resolve `L0^A' {*ABS* section} - `.LANCHOR0'
{.bss section}
/tmp/ccAfNLMj.s:932: Error: expression too complex
compiler exited with status 1
output is:
/tmp/ccAfNLMj.s: Assembler messages:
/tmp/ccAfNLMj.s:932: Error: can't resolve `L0^A' {*ABS* section} - `.LANCHOR0'
{.bss section}
/tmp/ccAfNLMj.s:932: Error: expression too complex
FAIL: gcc.c-torture/compile/pr60655-2.c -O3 -g (test for excess errors)
Excess errors:
/tmp/ccAfNLMj.s:932: Error: can't resolve `L0^A' {*ABS* section} - `.LANCHOR0'
{.bss section}
/tmp/ccAfNLMj.s:932: Error: expression too complex
Here's a port of the original ARM fix (commit 209269), that removes the
failure for me.
Regression-tested with the following powerpc-gnu-linux multilibs:
-mcpu=603e
-mcpu=603e -msoft-float
-mcpu=8540 -mfloat-gprs=single -mspe=yes -mabi=spe
-mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe
-mcpu=7400 -maltivec -mabi=altivec
-mcpu=e6500 -maltivec -mabi=altivec
-mcpu=e5500 -m64
-mcpu=e6500 -m64 -maltivec -mabi=altivec
OK for trunk and 4.9?
2014-09-02 Maciej W. Rozycki ma...@codesourcery.com
PR debug/60655
* config/rs6000/rs6000.c (rs6000_const_not_ok_for_debug_p):
Reject MINUS with SYM_REFs in different sections.
Maciej
gcc-rs6000-minus-not-ok-for-debug.diff
Index: gcc-fsf-trunk-quilt/gcc/config/rs6000/rs6000.c
===
--- gcc-fsf-trunk-quilt.orig/gcc/config/rs6000/rs6000.c 2014-08-26
20:30:10.348973028 +0100
+++ gcc-fsf-trunk-quilt/gcc/config/rs6000/rs6000.c 2014-09-01
17:09:23.748927487 +0100
@@ -6974,7 +6974,13 @@ rs6000_delegitimize_address (rtx orig_x)
/* Return true if X shouldn't be emitted into the debug info.
The linker doesn't like .toc section references from
- .debug_* sections, so reject .toc section symbols. */
+ .debug_* sections, so reject .toc section symbols.
+
+ Also as a temporary fix for PR60655 we reject certain MINUS
+ expressions. Ideally we need to handle most of these cases in
+ the generic part but currently we reject minus (..) (sym_ref).
+ We try to ameliorate the case with minus (sym_ref1) (sym_ref2)
+ where they are in the same section. */
static bool
rs6000_const_not_ok_for_debug_p (rtx x)
@@ -6988,6 +6994,35 @@ rs6000_const_not_ok_for_debug_p (rtx x)
return true;
}
+ if (GET_CODE (x) == MINUS)
+{
+ tree decl_op0 = NULL;
+ tree decl_op1 = NULL;
+
+ if (GET_CODE (XEXP (x, 1)) == SYMBOL_REF)
+ {
+decl_op1 = SYMBOL_REF_DECL (XEXP (x, 1));
+if (decl_op1
+ GET_CODE (XEXP (x, 0)) == SYMBOL_REF
+ (decl_op0 = SYMBOL_REF_DECL (XEXP (x, 0
+ {
+if ((TREE_CODE (decl_op1) == VAR_DECL
+ || TREE_CODE (decl_op1) == CONST_DECL)
+ (TREE_CODE (decl_op0) == VAR_DECL
+|| TREE_CODE (decl_op0) == CONST_DECL))
+ return (get_variable_section (decl_op1, false)
+ != get_variable_section (decl_op0, false));
+
+if (TREE_CODE (decl_op1) == LABEL_DECL
+ TREE_CODE (decl_op0) == LABEL_DECL)
+ return (DECL_CONTEXT (decl_op1)
+ != DECL_CONTEXT (decl_op0));
+ }
+
+return true;
+ }
+}
+
return false;
}
Re: [PATCH][PR debug/60655] Power/GCC: Reject cross-section symbol subtraction
On Tue, Sep 02, 2014 at 09:47:15AM -0400, David Edelsohn wrote: Alan, Any feedback? It is just papering over the real bug(s), of course, so I'd be inclined to say this doesn't belong on trunk. If you take a look at the assembly that is failing, you find gcc is trying to output a location expression for a parameter of mp_compare. After replacing the 335-.LANCHOR0 with 0: objdump -sj.debug_loc 0180 00f8 0104 0190 000f7a00 0300 00220300 0022 01a0 9f readelf -r 0195 0401 R_PPC_ADDR32 .bss + 0 readelf -wo 0188 00f8 0104 (DW_OP_breg10 (r10): 0; DW_OP_addr: 0; DW_OP_plus; DW_OP_addr: 0; DW_OP_plus; DW_OP_stack_value) Putting this all together, and knowing that .LANCHOR0 == .bss+0, the expresssion is really: 0188 00f8 0104 (DW_OP_breg10 (r10): 0; DW_OP_addr: .LANCHOR0; DW_OP_plus; DW_OP_addr: 335-.LANCHOR0; DW_OP_plus; DW_OP_stack_value) ie. ((r10) + 0) + (.LANCHOR0) + (335-.LANCHOR0) Clearly this could be simplified to (r10) + 335, so it might be that var-tracking is being confused by section anchors. However, it is more than just a missing simplification because the location expression doesn't make any sense at all.. In fact if you look at the corresponding location expression for -fno-section-anchors code you get something quite screwy too. 018f 0108 0114 (DW_OP_breg10 (r10): 0; DW_OP_addr: 144; DW_OP_plus; DW_OP_stack_value which is (r10) + modulus. If I have the interpretation of all the debug info correct, what this is saying is that in the epilogue of upton_modmult, the value for the r2 parameter of mp_compare is found by adding the address of modulus to the contents of r10. The correct answer is simply that the r2 parameter of mp_compare is in r10. On Tue, Sep 2, 2014 at 6:28 AM, Maciej W. Rozycki ma...@codesourcery.com wrote: Hi, Similarly to ARM, where this issue was seen originally, and likely many other targets, the Power ABI does not appear to have a relocation defined to support taking a difference of two symbols in different sections each. This is seen as a failure in gcc.c-torture/compile/pr60655-2.c: -- Alan Modra Australia Development Lab, IBM
