From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=nru3=62=xen0n.name=i.swmail@sourceware.org>
Received: from mailbox.box.xen0n.name (mail.xen0n.name [115.28.160.31])
	by sourceware.org (Postfix) with ESMTPS id A5C9E3858C54
	for <binutils@sourceware.org>; Thu,  2 Mar 2023 08:53:29 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A5C9E3858C54
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=xen0n.name
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xen0n.name
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xen0n.name; s=mail;
	t=1677747205; bh=KdeliWfGSMwjDJxUXL0zc84QInxLL1mDvNWfpwcl0+c=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=i+GXjbqQ4danezrWpoSS0z7nr8pYonin29o0Tdh5BkiABlmWUlj5rcaSPEO7QExET
	 vUp1sFSfco9csLSYBqkv1PbLJKTpE460UtOXxVlcENIAzfeBlpWYoU+yED6Y2i1aPy
	 gMGXFk4LLZPAemQQSKW5sIR7meXo0yMD099BeNhE=
Received: from [100.100.57.122] (unknown [58.34.185.106])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mailbox.box.xen0n.name (Postfix) with ESMTPSA id 8C176600D4;
	Thu,  2 Mar 2023 16:53:25 +0800 (CST)
Message-ID: <660c58cc-10bf-c43b-aded-27a27300cea3@xen0n.name>
Date: Thu, 2 Mar 2023 16:53:25 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.8.0
Subject: Re: [PATCH] elfedit: add support for editing e_flags
Content-Language: en-US
To: Xi Ruoyao <xry111@xry111.site>, WANG Xuerui <i.swmail@xen0n.name>,
 binutils@sourceware.org
Cc: Chenghua Xu <xuchenghua@loongson.cn>,
 Zhensong Liu <liuzhensong@loongson.cn>,
 Qinggang Meng <mengqinggang@loongson.cn>, WANG Xuerui <git@xen0n.name>
References: <20230302080137.3346439-1-i.swmail@xen0n.name>
 <502da978c3a38a5216a0d9abbbe3ebf22f8688e5.camel@xry111.site>
From: WANG Xuerui <i.swmail@xen0n.name>
In-Reply-To: <502da978c3a38a5216a0d9abbbe3ebf22f8688e5.camel@xry111.site>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <binutils.sourceware.org>

On 2023/3/2 16:20, Xi Ruoyao wrote:
> On Thu, 2023-03-02 at 16:01 +0800, WANG Xuerui wrote:
>
>> I have to pick up the work because I was trying to make AMDGPU DCN work
>> on LoongArch, but that piece of code requires hard-float support while
>> the LoongArch Linux kernel is compiled in the soft-float ABI, leading to
>> link-time failures intermixing the two.
> IMO we should keep soft-float ABI while enabling the FPU (i. e.
> -mabi=lp64s -mfpu=64).  But ouch, this does not work properly with
> current GCC...  -mfpu=64 silently enables using FPR to pass arg and
> return value, w/o even a warning.  Not sure about Clang.
>
> <rant>I remember I've been saying "floating ABI and floating instruction
> set should be de-coupled" multiple times: "I" in "ABI" stands for
> "interface" anyway and all the interfaces are just designed for hiding
> implementation details.  But it seems nobody took it seriously.</rant>

Yeah. I remember the Toolchain Conventions has similar words so I've 
immediately tried `-mdouble-float` without `-mabi=lp64d`, after seeing 
the rejected interlinks, only to see the ABI implicitly promoted to 
LP64D nevertheless...