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 [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 2F6B63858C30 for ; Mon, 4 Sep 2023 14:46:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2F6B63858C30 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1693838797; 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: in-reply-to:in-reply-to:references:references; bh=Epl2cubVuTQM/ZTsHBuBjZrp7tGOISfe+QL4QfWvDs8=; b=OP6LoW6TRBtBB3ksgv/VCUKyvF1FUHdozqIJrChYKaxavn5F43DVyVF1u2LMfrxPCNoi64 OGJGmXgt7sa6ONeXNzMqSNnfsEMgjZiFitDVg3ReDqjN5oF2gM4eKHVJpcHdkdWB82Xx+N 1RyVCTAIeoBuv52jigCniLVLcwGEr5Q= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-302-zQWfDCHVNIW8xdTe7-zeww-1; Mon, 04 Sep 2023 10:46:34 -0400 X-MC-Unique: zQWfDCHVNIW8xdTe7-zeww-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4E5F529DD99F; Mon, 4 Sep 2023 14:46:34 +0000 (UTC) Received: from oldenburg3.str.redhat.com (unknown [10.39.194.68]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B8BBB40C206F; Mon, 4 Sep 2023 14:46:33 +0000 (UTC) From: Florian Weimer To: Szabolcs Nagy Cc: "H.J. Lu" , libc-alpha@sourceware.org Subject: Re: [PATCH] Linux: Support non-variadic calls to prctl (bug 29770) References: <878rkiu72f.fsf@oldenburg.str.redhat.com> <87cz9usjn3.fsf@oldenburg.str.redhat.com> <878rkishbo.fsf@oldenburg.str.redhat.com> Date: Mon, 04 Sep 2023 16:46:32 +0200 In-Reply-To: (Szabolcs Nagy's message of "Fri, 11 Nov 2022 13:27:07 +0000") Message-ID: <8734zuuhbr.fsf@oldenburg3.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.8 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_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Szabolcs Nagy: >> I don't think that's true for our current ABIs. They support >> unprototyped calls, and by extension this also means that calls through >> a variadic prototype to a prototyped non-variadic function must work as >> well. There are other ABIs which do not work this way, but glibc hasn't >> been ported to them (and it's unclear how useful they would be for >> GNU/Linux). > > this is not true in general. > > unprototyped call to variadic functions is not valid in c. It is valid C before C99. GCC still accepts unprotyped calls with a warning in all C language modes, which is why I think we need to keep supporting it. > so unprototyped call abi does not have to match both the > variadic and non-variadic call abi. (only non-variadic calls > with arg types that promote to themselves need to work.) It's true that the ABI does not have to match exactly. We already have several ABIs where non-variadic calls to functions implemented as variadic functions fail. to my knowledge, we do not have something in the other direction (and we really can't, for pre-C99 support). The patch I posted avoids an ABI break on powerpc64le. > e.g. on arm variadic functions always take float args following the > soft float abi, but an unprototyped call with double args uses the > hard float abi on armhf (int vs float regs). How do you maintain C89 compatibility with such an ABI? I assume the difference is only in the non-variadic part. For the variadic part, float needs to be promoted to double. > i guess the prctl case works on existing abis now, but i think > future abis might want different variadic call abi (morello is an > example, though that's an experimental target). The ABIs are already different today on powerpc64le today, even for prctl. Variadic functions on powerpc64le assume additional setup by the caller, which does not happen with a non-variadic call. The man-pages project used to document prctl as a non-variadic function. > prctl is nasty because the arguments are often passed with the > wrong type (e.g. int arguments instead of unsigned long) and > with variadic prototype this can pass wrong value (e.g. non-zero > top bits on 64bit targets) down to the kernel. unfortunately > whatever glibc does internally won't solve this issue: the public > API would need to change. The C wrapper I'm fixing tries to solve this for the ILP32 with 64-bit syscall registers case. It's just that the original fix exposes another bug. Thanks, Florian