[PATCH] elfedit: add support for editing e_flags

[Xi Ruoyao]

On Thu, 2023-03-02 at 16:53 +0800, WANG Xuerui wrote:
> 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...

If I read the doc correctly, -mdouble-float implies both -mfpu=64 and -
mabi=lpxxd, while -mfpu=64 alone should not affect the calling
convention unless it's absolutely necessary (for e.g. -mfpu=32 -
mabi=lp64d can downgrade the ABI to lp64f).

I consider "-mfpu=64 silently changes -mabi=lp64s to -mabi=lp64d" a GCC
bug (behavior difference from the toolchain convention), now making a
GCC patch...
-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University