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
