Hi Jin Ma: I realized multilib os dir is not correctly set as you described, but I think that info should just come from multilib_select rather than creating a new hook to do that, anyway I just wrote a fix...because we hit that issue last week...
Hi Jeff: Here is another approach to fix that - without introducing new hook, just using existing info, also come with more simple step to reproduce and verify: https://gcc.gnu.org/pipermail/gcc-patches/2025-February/676540.html On Sat, Feb 22, 2025 at 10:51 PM Jeff Law <jeffreya...@gmail.com> wrote: > > > > On 2/22/25 7:31 AM, Palmer Dabbelt wrote: > > On Sat, 22 Feb 2025 02:19:03 PST (-0800), ji...@linux.alibaba.com wrote: > >> On Fri, 14 Feb 2025 21:03:46 +0800, Jin Ma wrote: > >>> Create a new hook to let target could override the multi-lib-os result. > >>> > >>> The motivation for this change arises from the fact that using > >>> TARGET_COMPUTE_MULTILIB to override the original multilib_dir can lead > >>> to unexpected behavior with multilib_os_dir. > >>> > >>> In our build scripts, we establish a connection between multilib_os_dir > >>> and multilib_dir. For example, in gcc/config/riscv/t-linux, we set > >>> multilib_os_dir to be the parent directory of multilib_dir. However, > >>> when TARGET_COMPUTE_MULTILIB overrides multilib_dir and returns a reused > >>> result for multilib_dir, multilib_os_dir ends up being identical to > >>> multilib_dir. This discrepancy is clearly inconsistent with our > >>> expectations. > >>> > >>> gcc/ChangeLog: > >>> > >>> * common/common-target.def (compute_multilib_os): New. > >>> * common/common-targhooks.cc (default_compute_multilib_os): New. > >>> * common/common-targhooks.h (default_compute_multilib_os): New. > >>> * doc/tm.texi (TARGET_COMPUTE_MULTILIB_OS): New. > >>> * doc/tm.texi.in: Regen. > >>> * gcc.cc (set_multilib_dir): Call targetm_common.compute_multilib_os. > >>> --- > >>> gcc/common/common-target.def | 14 ++++++++++++++ > >>> gcc/common/common-targhooks.cc | 9 +++++++++ > >>> gcc/common/common-targhooks.h | 5 +++++ > >>> gcc/doc/tm.texi | 10 ++++++++++ > >>> gcc/doc/tm.texi.in | 1 + > >>> gcc/gcc.cc | 4 ++++ > >>> 6 files changed, 43 insertions(+) > >> > >> Ping again :) > >> > >> Is there any comment on this patches? > > > > Not yet, I've got them open but I haven't had time to figure out the > > paths yet. I know we screwed this up the first time and need to do > > something, I'm just not really quite sure what the right answer is yet. > And I'm deeply concerned about adding another overriding target hook in > here. It feels like we're papering over a bigger problem elsewhere, but > I haven't had the time to really dive in to either articulate my > concerns more clearly or alleviate them. > > jeff >
