Re: Optimise away eh_frame advance_loc 0

[Alan Modra <amodra at gmail dot com>]

On Mon, Oct 28, 2019 at 04:16:30PM +0000, Joseph Myers wrote:
> This breaks the build of glibc for sh4-linux-gnu (confirmed this is the 
> revision that introduces the breakage) and mips64-linux-gnu (not tested 
> the specific revisions, but the symptoms are the same so it looks like 
> the same breakage).
> 
> https://sourceware.org/ml/libc-testresults/2019-q4/msg00129.html
> 
> I've attached malloc.s (gzipped) from an sh4-linux-gnu glibc build.  The 

Thanks.

> symptom is:
> $ sh4-glibc-linux-gnu-as -little -o malloc.o malloc.s
> malloc.s: Assembler messages:
> malloc.s: Fatal error: can't write -1 bytes to section .debug_frame of malloc.o: 'bad value'
> 

Looks like I committed the sin that catches all new gas developers
(and even this old one) of assuming no frag breaks at critical points.
The following should fix it.  I'll commit this after running some tests.

diff --git a/gas/dw2gencfi.c b/gas/dw2gencfi.c
index b01e4c4a9e..6c0478a720 100644
--- a/gas/dw2gencfi.c
+++ b/gas/dw2gencfi.c
@@ -1630,7 +1630,12 @@ output_cfi_insn (struct cfi_insn_data *insn)
 	    /* The code in ehopt.c expects that one byte of the encoding
 	       is already allocated to the frag.  This comes from the way
 	       that it scans the .eh_frame section looking first for the
-	       .byte DW_CFA_advance_loc4.  */
+	       .byte DW_CFA_advance_loc4.  Call frag_grow with the sum of
+	       room needed by frag_more and frag_var to preallocate space
+	       ensuring that the DW_CFA_advance_loc4 is in the fixed part
+	       of the rs_cfa frag, so that the relax machinery can remove
+	       the advance_loc should it advance by zero.  */
+	    frag_grow (5);
 	    *frag_more (1) = DW_CFA_advance_loc4;
 
 	    frag_var (rs_cfa, 4, 0, DWARF2_LINE_MIN_INSN_LENGTH << 3,

-- 
Alan Modra
Australia Development Lab, IBM