From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 309433858C2C; Thu, 10 Feb 2022 20:57:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 309433858C2C From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug ports/28872] Building glibc for MIPSel single float targets Date: Thu, 10 Feb 2022 20:57:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: ports X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: critical X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2022 20:57:53 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28872 --- Comment #11 from Adhemerval Zanella --- (In reply to Den from comment #10) > (In reply to Adhemerval Zanella from comment #9) > > I am trying to understand which options you use with gcc to target this > > chip,=20 > > -mabi=3D32 -march=3Dmips2 -mhard-float -msingle-float -mfp32 > That's correct. -march=3Dr6000 but yes it is mips2 anyway. >=20 > > seems to use > > 'sw/lw' to > > load store doubles. > I do not think that if to replace all of the s.d/l.d to sw/lw respectively > will do the trick. I am not really proposing it, I am in fact trying to understand what gcc em= its in such case. For instance, $ cat f.c void foo (double *x, double y) { *x =3D y; } $ mips64el-glibc-linux-gnu-gcc -O3 -mabi=3D32 -march=3Dr5900 -mhard-float -msingle-float -mfpxx f.c -S -o - .file 1 "f.c" .section .mdebug.abi32 .previous .nan legacy .module singlefloat .module oddspreg .abicalls .option pic0 .text .align 2 .globl foo .set nomips16 .set nomicromips .ent foo .type foo, @function foo: .frame $sp,0,$31 # vars=3D 0, regs=3D 0/0, args=3D 0= , gp=3D 0 .mask 0x00000000,0 .fmask 0x00000000,0 sw $6,0($4) .set noreorder .set nomacro jr $31 sw $7,4($4) [...] So I am trying to understand how/when gcc does the double emulation that replaces s.d by a two sdc1. >=20 > Let's summarize. > There is no way to somehow split a doubleword to a two words and vice ver= sa > conversion/uniting; My understanding is you do not need split, you just to need to save/restore the floating point values in the correct offsets in jmp_buf. The issue is if the application trying to access the registers values using a different type would see a double value which is different than float (I think maybe you will need to float-extend the values before writting them down on jmp_b= uf). > An extra ABI is required to be specified as to be thought-out. No one will > be handling that because of it's rarity; even if the processor itself, it= 's > model, is not rare; It is really unfortunate to add *another* mips abi because of this idissioncracy. > Most of the programs compiled basely on glibc with my patch are providing= a > SegFault, invalid write access. Patch is a waste, it's conception is wron= g. Is the segfault due the patch or is it another issue in fact? Afaik there = is no floating-point support on loader and it is localized on specific cases in libc.so. >=20 > Verdicts are: > patch is not worth to be accepated, even to be existing; Patch is not accepable *as-is*, I think it still possible to fix the context functions to correctly work on the chip you are using. > glibc can not be built for MIPSel targets with single float only; > thread closed; > invalid (to be as a) bug request. --=20 You are receiving this mail because: You are on the CC list for the bug.=