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: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 6E25A1F8C8 for ; Mon, 20 Sep 2021 16:42:19 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1D4843858427 for ; Mon, 20 Sep 2021 16:42:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1D4843858427 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1632156138; bh=LPJs5eqVakeUVdHKq/G0bWxuxcs0X9649w2Ko6AQo8Y=; h=To:Subject:In-Reply-To:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:From; b=G3T5KBqLiChdnG5/sdpEF1ddtJb3xyvnbblyy3Nql5Hki3v22aV6hL2Czw5LCfxnw lYcxEZPgMKJS+UKfsk/bZKR4XWUOiALPG9aiXxgv2PkygL3U2wT2qVeXcRxsGvycBU X4BPuVMSFP9Y3jBefmy3CCOhTpW321T07S6/O8/Q= 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 256AD3858D3C for ; Mon, 20 Sep 2021 16:41:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 256AD3858D3C 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-179-vab9iUVtOGiysnUNNBireQ-1; Mon, 20 Sep 2021 12:41:56 -0400 X-MC-Unique: vab9iUVtOGiysnUNNBireQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5909A802B9F; Mon, 20 Sep 2021 16:41:55 +0000 (UTC) Received: from greed.delorie.com (ovpn-112-2.rdu2.redhat.com [10.10.112.2]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EAD061002EF0; Mon, 20 Sep 2021 16:41:54 +0000 (UTC) Received: from greed.delorie.com.redhat.com (localhost [127.0.0.1]) by greed.delorie.com (8.15.2/8.15.2) with ESMTP id 18KGfrP31894783; Mon, 20 Sep 2021 12:41:53 -0400 To: Vincent Chen Subject: Re: [RFC patch 2/5] RISC-V: Reserve about 5K space in mcontext_t to support future ISA expansion. In-Reply-To: Date: Mon, 20 Sep 2021 12:41:53 -0400 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: DJ Delorie via Libc-alpha Reply-To: DJ Delorie Cc: libc-alpha@sourceware.org Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" Vincent Chen writes: > I am not familiar with the mechanism of LD_AUDIT, so I actually do not > know if this modification may have any effect on LD_AUDIT. If > possible, could you briefly introduce the issues for me? Thank you > very much. In general, when function foo() calls DSO function bar(), and bar() is in an object that needs to be loaded from disk, the loader needs to save foo()'s context, do a bunch of work, restore the context, and call bar(). The LD_AUDIT feature adds a lot more "do a bunch of work" both on the foo->bar call, and on the bar->foo return, typically calling some third party functions to process the audit messages. However, if the "do a bunch of work" changes registers that aren't saved in the context, and aren't agreed on as "call clobbered" and thus changeable, problems happen. If foo() expects a register to be preserved across the call to bar(), and the loader and audit functions don't know that and clobber it, foo() breaks. If everything is built with the same ISA, this normally isn't a problem, but when you mix ISAs, or use optional/experimental ISAs that glibc (or the auding code) doesn't know about, it may be.