FreeChainXenon/binutils-gdb
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Re: Optimise away eh_frame advance_loc 0

Browse source 
If we happen to get the fixed and variable parts of the advance_loc
in different frags, bad things happen when subtracting one from a
fr_fix of zero.

	PR 25125
	* dw2gencfi.c (output_cfi_insn): Don't allow DW_CFA_advance_loc4
	to be placed in a different frag to the rs_cfa.
This commit is contained in:
Alan Modra 2019-10-29 11:35:05 +10:30
parent d7b510baa8
commit b9d8f5601b
2 changed files with 12 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
gas/ChangeLog
View file

@ -1,3 +1,9 @@
2019-10-29 Alan Modra <amodra@gmail.com>
PR 25125
* dw2gencfi.c (output_cfi_insn): Don't allow DW_CFA_advance_loc4
to be placed in a different frag to the rs_cfa.
2019-10-26 John David Anglin <danglin@gcc.gnu.org>
PR gas/25121

7
gas/dw2gencfi.c
View file

@ -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,