bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/28410] Prevent region check failures when relaxation is not fina


From: nelsonc1225 at sourceware dot org
Subject: [Bug ld/28410] Prevent region check failures when relaxation is not final
Date: Thu, 07 Oct 2021 05:41:27 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=28410

--- Comment #7 from Nelson Chu <nelsonc1225 at sourceware dot org> ---
> only restart the relax passes themselves.

The purpose of `again` is used to rerun the relax passes themselves.  That
means once the `again` is always false for all input sections, and we decide to
enter the next relax pass, then we don't have any obvious method that can move
forward and rerun the previous relax passes.  So that's what the commit ebdcad
did, try to restart the relax passes without changing generic code, but it
causes the region check problem that you mentioned.

> However I do need to understand the original motivation for
> restarting the set of relax passes

The root cause is that I separate the pcgp relaxations from the relax pass 0 to
a new relax pass.  Why I separate the pcgp relaxations was mentioned in the
commit abd20c, and that's why I had suggest that we probably shouldn't separate
them to a new relax pass, we should try to modify the pcgp tables when
relaxing.  This is the option 3.

> I was thinking more about option 2. If I were to rewrite the system of
> restarting the whole set of relax passes without modifying `again` it should
> solve this bug.

If you have any idea for option 2 that won't change the generic code, then
that's also a choice, welcome to share it and we are listening.  There may be a
way, but we have to clarify some issues,

1. I prefer to keep the current `again' mechanism, and don't change the
info->relax_pass in the _bfd_riscv_relax_section.  In the lang_relax_sections,
we can only run `link_info.relax_pass` times at most, and use `again` to rerun
the relax passes themselves, so only changing the info->relax_pass in the
_bfd_riscv_relax_section will not solve the problem.

2. So I thought of a way before - we can just rerun the relax passes 0 itself,
but we separate the relaxations to many sub relax passes by a target variable 
riscv_relax_pass in the riscv_elf_link_hash_table.  For example, we do the
lui/call relaxations when riscv_relax_pass is 0, and we do the pcgp relaxations
when riscv_relax_pass is 1.  We can set the `again` to true when we are
rerunning the riscv_relax_pass 0->1->0->1->0->..., and in fact we are still in
the loop of relax pass 0.

But the problem is that - How do we know when to change the riscv_relax_pass in
the _bfd_riscv_relax_section, without modifying generic code?  Perhaps we could
run an extra relax pass at first, and then record the first and last input
sections.  So that we can restart the riscv_relax_pass when the input section
is the last one we have recorded.  But I'm not sure if recording the first and
last sections of a relax round is a good idea or not.  However, if you have any
good idea for the option 2, please feels free to try it.  Just that we should
try our best that don't modify any generic code.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]