[PATCH] elfedit: add support for editing e_flags

[Xi Ruoyao]

On Thu, 2023-03-02 at 19:02 +0800, WANG Xuerui wrote:
> > $ cc t.c -O2 -mabi=lp64s -mfpu=64 -c
> > $ readelf -a t.o | grep FLOAT
> >     Flags:                             0x41, SOFT-FLOAT, OBJ-v1
> > 
> > But then bad thing happens:
> > 
> > $ objdump -d t.o
> > 
> > t.o:     file format elf64-loongarch
> > 
> > 
> > Disassembly of section .text:
> > 
> > 0000000000000000 <t>:
> >      0: 01145800        frecip.d        $fa0, $fa0     <= you can't expect the arg in the god-damn $fa0!
> >      4: 4c000020        jirl            $zero, $ra, 0  <= you can't just return the answer in $fa0!
> > 
> > This is completely broken.  However if your elfedit hack will "work",
> > this will "work" too anyway.

FWIW: GCC patch is now
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613215.html.

> Mixing calling conventions is currently problematic in general, true. 
> But in amdgpu's case things will work just fine, because discipline is
> used throughout to ensure (a) no FP argument is passed across the 
> boundary between FPU-enabled code and the rest, and (b) any such 
> boundary-crossing method takes care to save/restore FPU context 
> appropriately. You can argue this is the general case in kernel land, even.

Yes, it seems some other architectures are using this trick for DCN.

(I'd planned to port the DCN driver several weeks later, but I guess
you've already completed it now.  And frankly I didn't expect the
misbehavior of GCC :)
-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University