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=-3.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_GMAIL_RCVD, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,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=no 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 CEC951F463 for ; Wed, 8 Jan 2020 22:56:38 +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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=bDA5 Jr0bWAdIpVbNyjwH8wxMejbn09QUiry5pchGOzxHMsaK/pDX4BarYVc6fDwBQ2KG AXrQXxaLgx/Rydf+OWI5a3BheJmgSoZG6Blrbdu/MXC0HPjk1DqjHu758Msoju3V tZ2EZeZcpr9lPfp6P9Gj331IzBIv+P+gyrjUFvE= 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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; s=default; bh=kvyU3lHbi1 qSvehKe2mrWBf5mNM=; b=y4trZ7heqJ+qzWvVKuq1IR8RiAqIXv0lC2wP6O8O8c CEb8F1p14STAJ3ogY+uJFe2uFyqxe4yoHb8zHgKKy+b+Y7zk4bw2oggABSt3MgFF XjmFLr0qeKV1G1f1pg734swJr50zHLhNGT0sQNBd+yXQ5ufQ+gsGFggpD4h88ihv c= Received: (qmail 118583 invoked by alias); 8 Jan 2020 22:56:36 -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 118575 invoked by uid 89); 8 Jan 2020 22:56:36 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-ot1-f42.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WOTrBTOkPwKN2kemg/nX2xso47rdy1GR7rWl0mQ4xKs=; b=R4W4rGfId7jiNK/4ve2MR3sOAsKkpmisbXvZTO9ejxQziE+bqwcZD5G3wqnq9G80jL jOHrLgP9rAQK+PwaoCGC06LF47WTJ0dfnJBBJluEOoNu8Uu7QkdQmQH+t6beao9VBkWL zuU2C1AJQJvqxKeJ8qx3Q3TMfQ7wt1vRNoE/AHr0CzTnXmgt93SwEAHgRluqeD4gWbvf wIixI29TWthSj8fxXSIL4NNSK0DQjZ0KM1cgNpaei4GbQ3CSovBJKvtwydZeQHsDJKDF ae09IwLCQaE3CskSkhr0iN7b6PrEGym5GT0sFrz5M0S2Hc6W98d1bI9Ti52LUu979SrH 1cmQ== MIME-Version: 1.0 References: <87lfra2as7.fsf@oldenburg2.str.redhat.com> In-Reply-To: <87lfra2as7.fsf@oldenburg2.str.redhat.com> From: "H.J. Lu" Date: Wed, 8 Jan 2020 14:55:57 -0800 Message-ID: Subject: Re: i386: Lazy binding trampoline and vector register usage To: Florian Weimer Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" On Wed, Dec 18, 2019 at 2:22 AM Florian Weimer wrote: > > 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 += -mno-sse -mno-mmx -mfpmath=387 > ifeq ($(subdir),elf) > CFLAGS-.os += $(if $(filter $(@F),$(patsubst %,%.os,$(all-rtld-routines))),\ > $(rtld-CFLAGS)) > > tests-special += $(objpfx)tst-ld-sse-use.out > $(objpfx)tst-ld-sse-use.out: ../sysdeps/i386/tst-ld-sse-use.sh $(objpfx)ld.so > @echo "Checking ld.so for SSE register use. This will take a few seconds..." > $(BASH) $< $(objpfx) '$(NM)' '$(OBJDUMP)' '$(READELF)' > $@; \ > $(evaluate-test) > else > CFLAGS-.os += $(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? Yes, we can do it for i386. > (I found this by code inspection. I have not seen actual crashes/wrong > results at run time.) Thanks. -- H.J.