From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id A24B1385DC1A for ; Thu, 26 Nov 2020 12:39:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A24B1385DC1A Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-281-47a9_1nPO4GCAv_Qwpmt6w-1; Thu, 26 Nov 2020 07:38:54 -0500 X-MC-Unique: 47a9_1nPO4GCAv_Qwpmt6w-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EE1671927807; Thu, 26 Nov 2020 12:37:55 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-112-141.ams2.redhat.com [10.36.112.141]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4056919C71; Thu, 26 Nov 2020 12:37:55 +0000 (UTC) From: Florian Weimer To: Huang Pei Cc: libc-help@sourceware.org Subject: Re: Question about setjmp_aux.c on MIPS References: <20201126120337.c7lsjbzlhrskzx7k@ambrosehua-HP-xw6600-Workstation> Date: Thu, 26 Nov 2020 13:37:53 +0100 In-Reply-To: <20201126120337.c7lsjbzlhrskzx7k@ambrosehua-HP-xw6600-Workstation> (Huang Pei's message of "Thu, 26 Nov 2020 20:03:37 +0800") Message-ID: <87tutcnvj2.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 12:39:02 -0000 * Huang Pei: > For ld.so, it is not intended to use floating point instruction, but the > __sigsetjmp from _dl_catch_exception touch FP regs repeatedly as loading > DSOs, which cause unneeded FP context saving and restoring between tasks > that does not use FP at all, I wonder if this can be avoided. I think I have posted patches to move _dl_catch_exception into ld.so (=E2=80=9Celf: Rework exception handling in the dynamic loader [BZ #25486]= =E2=80=9D). Once they are merged, you could special-case setjmp for use within ld.so not to save & restore floating point state when compiled for IS_IN (rtld). > +. MIPS, link other RISC with hard floating point suppport need to save= =20 > callee-saved FP in setjmp_aux.c, but setjmp.S for x86/x86_64 DOES NOT > save any x87/SSE regs, does anyone know why? The official x86-64 ABI does not have any non-volatile/callee-saved floating point registers. We have code to save and restore floating point state in the lazy binding trampoline because floating point registers are used to pass arguments and return results, but that's it. > +. Does MIPS need to save MSA reg as PowerPC does for VSX in setjmp_aux.c= ? Hard to tell, it really depends on ABI details. > +. I see x86/x86-64/ARM64 say no need to save sigmask in ld.so, can > MIPS does this too? I think so, yes. Thanks, Florian --=20 Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'N= eill