[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