[PATCH] Make sure DW_CFA_advance_loc4 is in the same frag

[Jan Beulich]

On 30.08.2023 05:35, Jinyang He wrote:
> How about this patch state?

As said before, Alan approved your change, so you're okay to commit. In
the subsequent discussion he explained to me why what I was suggesting
wasn't really correct.

Jan

> On 2023-08-11 18:15, Alan Modra wrote:
>> 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
>