From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 0B5141F463 for ; Wed, 18 Dec 2019 10:22:46 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id :mime-version:content-type:content-transfer-encoding; q=dns; s= default; b=aCaOMSgEUokrxv4RWietP47sPkXDW6Eo1aHj2EFNH80u/xj/SoqBA FlRnkHEEV+E8kZ22tzBlRVd+UfFGvJo/kmdVbeM8Mf8dldFKg127NUzZryY9fOlo sQDwju25TNg7I7n4VzBoxAfvH/2LvtzrGJ2VLa+Nek3AwmjPOOIYJ0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id :mime-version:content-type:content-transfer-encoding; s=default; bh=0ChZh07EhHpIPWd5IgU0XRLN9F0=; b=OiKlz9eXJ1u2zEfk7k5usNHiavDv vatIlftuXwGyQUuSbzVhHHhwqthd3nYv/3b7bn+Kbv16yXe6IXwF9loMjbBPWz37 MPzn2v1I70TTAbdC10g4/AJ9TlayBRMy8iTWZYtcvIuEAV7wEGvykaHqd3gJrQFp Vxs/VH/1dOwXl9w= Received: (qmail 117990 invoked by alias); 18 Dec 2019 10:22:43 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 117924 invoked by uid 89); 18 Dec 2019 10:22:42 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: us-smtp-delivery-1.mimecast.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576664560; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Io6GrC0kIPcrxe65e/NVS0zDEiUPELl3oce4LK1gGQs=; b=aBcrcpgEB/vbqDN4xI+AY94MyeCmWxSr1iCSBK6o+UgNMkckbv+VI9nytXhlL6Sv1HH2lq agpnk2J8FtTjIniNZqdsGPtn0m8pcwluCXnJ9ABis0n4/HAwHBoDh7h7Mjg/jT2tgu6fLn 5yXPXKTUDP0Na/ievV/9g/WTaHlqxZU= From: Florian Weimer To: "H.J. Lu" Cc: libc-alpha@sourceware.org Subject: i386: Lazy binding trampoline and vector register usage Date: Wed, 18 Dec 2019 11:22:32 +0100 Message-ID: <87lfra2as7.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable We have this in sysdeps/i386/Makefile: # Make sure no code in ld.so uses mm/xmm/ymm/zmm registers on i386 since # the first 3 mm/xmm/ymm/zmm registers are used to pass vector parameters # which must be preserved. # With SSE disabled, ensure -fpmath is not set to use sse either. rtld-CFLAGS +=3D -mno-sse -mno-mmx -mfpmath=3D387 ifeq ($(subdir),elf) CFLAGS-.os +=3D $(if $(filter $(@F),$(patsubst %,%.os,$(all-rtld-routines))= ),\ =09=09 $(rtld-CFLAGS)) tests-special +=3D $(objpfx)tst-ld-sse-use.out $(objpfx)tst-ld-sse-use.out: ../sysdeps/i386/tst-ld-sse-use.sh $(objpfx)ld.= so =09@echo "Checking ld.so for SSE register use. This will take a few second= s..." =09$(BASH) $< $(objpfx) '$(NM)' '$(OBJDUMP)' '$(READELF)' > $@; \ =09$(evaluate-test) else CFLAGS-.os +=3D $(if $(filter rtld-%.os,$(@F)), $(rtld-CFLAGS)) endif The idea is that we do not need to save and restore vector registers in the trampoline (or align the stack) if we compile ld.so in such a way that only general registers are used. But that does not actually work in all cases because lazy binding can call malloc, which lives in libc.so or might even be interposed, and is thus free to use vector registers. What should we do about this? Calling malloc from _dl_fixup is unsafe for other reasons because lazy binding can happen in signal handlers, so maybe this would be fixed if we switched to a non-interposable async-signal-safe allocator? (I found this by code inspection. I have not seen actual crashes/wrong results at run time.) Thanks, Florian