[PATCH] Make sure DW_CFA_advance_loc4 is in the same frag

Alan Modra amodra@gmail.com
Fri Aug 11 10:15:35 GMT 2023


On Fri, Aug 11, 2023 at 10:27:53AM +0200, Jan Beulich wrote:
> On 11.08.2023 01:02, Alan Modra wrote:
> > On Thu, Aug 10, 2023 at 02:55:20PM +0200, Jan Beulich wrote:
> >> On 10.08.2023 14:36, Jinyang He wrote:
> >>> On /Thu Aug 10 07:55:58 GMT 2023 /Jan Beulich wrote:
> >>>
> >>>> On 10.08.2023 04:21, Jinyang He wrote:
> >>>>> /The DW_CFA_advance_loc4 may be in different frags. Then fr_fix />/may caused something wrong. Referenced by commit b9d8f5601bcf />/("Re: Optimise away eh_frame advance_loc 0"). /
> >>>> I'm afraid I don't understand that earlier fix: frag_more(1) there
> >>>> ought to guarantee fr_fix (once the frag is closed) to be >= 1.
> >>>> It would then seem to me that ...
> >>>
> >>> I'm not familiar with it. Please point out my mistakes. Thanks in advance.
> >>
> >> Well, Alan has approved your change. Maybe it's me who is wrong here.
> > 
> > The idea behind commit b9d8f5601bcf was that when a
> > DW_CFA_advance_loc4 of zero is seen in eh_frame_relax_frag and
> > eh_frame_convert_frag we want to remove the opcode entirely, not just
> > convert to a nop.  If the opcode was split over two frags then the
> > size adjustment would need to be done to the first frag, not the
> > second as is correct for other cases with split frags.  This would
> > complicate the eh relaxation.  It's easier to ensure the frag is not
> > split.
> 
> Oh, right, I can see that this makes things easier. But for the change
> here, does frag_grow() actually help preventing the split?

Yes.

> Wouldn't it
> need to be yet beyond what I suggested and require frag_more(5),

No, because frag_more would move the obstack data pointer, and we want
to leave that to the caller of check_eh_frame.

> such
> that intermediate section switches wouldn't close off the first frag?

That shouldn't happen.  check_eh_frame only does something when
processing .eh_frame or .debug_frame sections.

> Of course this would collide with what you say regarding size
> adjustments needing to happen on the 2nd (variable) frag. (Aiui just
> frag_grow() is enough in output_cfi_insn(), as there we aren't at risk
> of intermediate section changes.)
> 
> Jan

-- 
Alan Modra
Australia Development Lab, IBM


More information about the Binutils mailing list