Message ID | 38183c29-9b7f-4960-8702-d71ce816cf80@p183 |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp1738600vqy; Sat, 2 Dec 2023 04:45:26 -0800 (PST) X-Google-Smtp-Source: AGHT+IF3RakbfZfFtMas6RUwniW7aSbSNaDqyS2brj7zi8853db7C6dKJzNU78+rhPN5JvJHee3S X-Received: by 2002:a05:6a20:139a:b0:18b:ca68:4e9a with SMTP id hn26-20020a056a20139a00b0018bca684e9amr995177pzc.28.1701521126326; Sat, 02 Dec 2023 04:45:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701521126; cv=none; d=google.com; s=arc-20160816; b=tHZuXOc4YOI/pyTCOygmfPfNPu9TYQse1Cc1Sy2xwFRYPmaptVoPOdIGI8QP4yhb5s Cp3K4KMdSrRHYJlRk1O8F1tC49g0x6FKRYdNqHNStlfMZYP1OlfemGAo+EMurY3LRuA7 2YrP9vt1NwegmXtU74DJ6jB8v/LCKlBxelWeKOSuz2STjcWgLIaKGhoQkPaSiAEcOYAA IyIzON8z+EAhSLw58gkI4pyudABFKXx/EldNXBgw4//8zlqKMuAFZHUcWYaQu3B2xgXR wQ4nBNaIzYhkp/ZLQRYL1gZXiqoEdjt6b0v4bGgHTUZY8U1gp+55s0lDNdqmb/QqjshL h/rA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:cc:to:from:date:dkim-signature; bh=1g8MqwHZBgoNHWh+bYkNb6sIC9zXf19tQTXlJc9qQOU=; fh=C3p1y84NoTy63snxPjpHMdN9GmyIjPnfMy2Eaa+sWwg=; b=M7ms9QcHd8x6K5rGd+YBhIpmljGh6ZhkijvzHaAfV2gqpi9iw63uJz84RkFd4p70BB XqAHf1KYjzYoEDrW1sNKpVxZ374+f+FmlgXBEtmI0PCiakKy08HeoRLHFqqL3ui/8J+r n3et2XtD0K4Ru7kiF5i4UYfTmIIbaEQ5uQE7WaK8BAJ0EGY5kxXcni2q/GBO8A3yr50R 3gp3qiqbUj0bBHyb3BvDmVZO6OVWYpyI2gypl50Y2vUGMKJoy9Vok2Fsy+w5nPLmCrNR zmv5gV9ZE9U7G7HVe5yvWrSdEwPvKhDmzX64hlVeviW4LNEsOtJGX58oyJ/FZqheoroS h5cw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=CYkZ+IAi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id n126-20020a632784000000b005c671034479si33722pgn.490.2023.12.02.04.45.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 04:45:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=CYkZ+IAi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id C3579808EDE2; Sat, 2 Dec 2023 04:45:21 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232138AbjLBMpN (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Sat, 2 Dec 2023 07:45:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229702AbjLBMpL (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 2 Dec 2023 07:45:11 -0500 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A748184 for <linux-kernel@vger.kernel.org>; Sat, 2 Dec 2023 04:45:17 -0800 (PST) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a1882023bbfso392438466b.3 for <linux-kernel@vger.kernel.org>; Sat, 02 Dec 2023 04:45:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701521115; x=1702125915; darn=vger.kernel.org; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=1g8MqwHZBgoNHWh+bYkNb6sIC9zXf19tQTXlJc9qQOU=; b=CYkZ+IAixkiWTz0S2FqHBXNvQ6WQ29Wihd3rxHw/7hQSM7xyBki8h23POPGAXRubga x1vQboO7th1i7ZJi6Ou+B099ztmrfy8uL4vtf8NEHIFDtAUkk6rZFlxaZaiK0UwGQB5T DBY8mtehKl+Wn4DneWzIKX24SMy3Ri6PwUyDKZNmrTRE8Ki3Z4cZzSdALxPFnCkIlTgS hw7xZkE4XbLdQftoYWgedK9kyDxIzrV4bXTgrhAO9WDou3c7iJ4cVhTQ7pSgjucD2M+G k5xyotlIxKAEu6vcruUYh3mXSBdkLCUjbfBNh0fn5qrd4p73AgJfE+j0jX4+9ntmfFbh Q6FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701521115; x=1702125915; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1g8MqwHZBgoNHWh+bYkNb6sIC9zXf19tQTXlJc9qQOU=; b=q7ER4/fg+vOccORWo3TQRMAsDEgtZH9KbGZWeT4xya7Y+eHnTrgyPGIoy3rHPpG75N oc2cRK6X+4OwN2OokUcHfw0bWnc8sBzyon+3IMZzzoa/Ny3ggGFL4peCbdaDpYNcfwdI zbvby/J8j+KyT1Pv/tihuhC1jHlpHVzvsSP20Jg1jYBCquuLq7wa67GwmX/Sb/JgehAW TMF/I9lY5iNiJpLOmliCB86IJQ4VuvII2/cZZKe/sxcUpHHxMzCu6U/HTcvwvn4nZ9XH JxYrbHoWux+2SDxm/dE+kjkQnimjm0TQAS8lejfQjZdQTEE3CGKvpWCxzVo81R5pZ9A7 Is3A== X-Gm-Message-State: AOJu0Yz5Kr2Vm1Nmv5mEu/FSmC3FsT/j+xgOG97Nt1TrFPc17X3Nw5Fu KRq0fjf448idEmwJqpjPZ0BFI3jdMA== X-Received: by 2002:a17:906:fb99:b0:9e6:38f2:8439 with SMTP id lr25-20020a170906fb9900b009e638f28439mr1457788ejb.60.1701521115337; Sat, 02 Dec 2023 04:45:15 -0800 (PST) Received: from p183 ([46.53.252.219]) by smtp.gmail.com with ESMTPSA id qz1-20020a170907680100b00a1a25e756d4sm1658139ejc.107.2023.12.02.04.45.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 04:45:14 -0800 (PST) Date: Sat, 2 Dec 2023 15:45:13 +0300 From: Alexey Dobriyan <adobriyan@gmail.com> To: Willy Tarreau <w@1wt.eu>, Thomas =?utf-8?q?Wei=C3=9Fschuh?= <linux@weissschuh.net> Cc: linux-kernel@vger.kernel.org Subject: [PATCH] nolibc: optimise _start() on x86_64 Message-ID: <38183c29-9b7f-4960-8702-d71ce816cf80@p183> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Sat, 02 Dec 2023 04:45:21 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784174216448174497 X-GMAIL-MSGID: 1784174216448174497 |
Series |
nolibc: optimise _start() on x86_64
|
|
Commit Message
Alexey Dobriyan
Dec. 2, 2023, 12:45 p.m. UTC
Just jump into _start_c, it is not going to return anyway.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
Also, kernel clears all registers before starting process,
I'm not sure why
xor ebp, ebp
was added.
tools/include/nolibc/arch-x86_64.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Comments
Hi Alexey, On Sat, Dec 02, 2023 at 03:45:13PM +0300, Alexey Dobriyan wrote: > Just jump into _start_c, it is not going to return anyway. Thanks, but what's upper in the stack there ? I'm trying to make sure that if _start_c returns we don't get a random behavior. If we get a systematic crash (e.g. 0 always there) that's fine, what would be annoying would be random infinite loops etc. In the psABI description (table 3.9) I'm seeing "undefined" before argc, which I don't find much appealing. > Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> > --- > > Also, kernel clears all registers before starting process, > I'm not sure why > > xor ebp, ebp > > was added. Hmmm psABI says: Only the registers listed below have specied values at process entry: %rbp The content of this register is unspecied at process initialization time, but the user code should mark the deepest stack frame by setting the frame pointer to zero. %rsp The stack pointer holds the address of the byte with lowest address which is part of the stack. It is guaranteed to be 16-byte aligned at process entry. %rdx a function pointer that the application should register with atexit (BA_OS). Thus apparently it's documented as being our job to clear it :-/ Willy
On Sat, Dec 02, 2023 at 02:23:59PM +0100, Willy Tarreau wrote: > Hi Alexey, > > On Sat, Dec 02, 2023 at 03:45:13PM +0300, Alexey Dobriyan wrote: > > Just jump into _start_c, it is not going to return anyway. > > Thanks, but what's upper in the stack there ? argc (gdb) break _start (gdb) run (gdb) x/20gx $sp 0x7fffffffdae0: 0x0000000000000004 0x00007fffffffdf33 0x7fffffffdaf0: 0x00007fffffffdf49 0x00007fffffffdf4b 0x7fffffffdb00: 0x00007fffffffdf4d 0x0000000000000000 0x7fffffffdb10: 0x00007fffffffdf4f 0x00007fffffffdf70 0x7fffffffdb20: 0x00007fffffffdf80 0x00007fffffffdfce (gdb) x/s 0x00007fffffffdf33 0x7fffffffdf33: "/home/ad/s-test/a.out" > I'm trying to make sure > that if _start_c returns we don't get a random behavior. Yes, it should segfault executing from very small address. I tested with .intel_syntax noprefix .globl _start _start: ret mov eax, 231 xor edi, edi syscall > If we get a > systematic crash (e.g. 0 always there) that's fine, what would be > annoying would be random infinite loops etc. In the psABI description > (table 3.9) I'm seeing "undefined" before argc, which I don't find > much appealing. > > > Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> > > --- > > > > Also, kernel clears all registers before starting process, > > I'm not sure why > > > > xor ebp, ebp > > > > was added. > > Hmmm psABI says: > > Only the registers listed below have specied values at process entry: > > %rbp The content of this register is unspecied at process initialization > time, but the user code should mark the deepest stack frame by setting > the frame pointer to zero. > > %rsp The stack pointer holds the address of the byte with lowest address > which is part of the stack. It is guaranteed to be 16-byte aligned at > process entry. > > %rdx a function pointer that the application should register with atexit (BA_OS). > > Thus apparently it's documented as being our job to clear it :-/ I meant, ELF loader clears all registers except rsp and aligns the stack to 16 bytes. There were problems with stack aligning, but registers, I think, were always zeroed.
On Sun, Dec 03, 2023 at 03:00:48PM +0300, Alexey Dobriyan wrote: > On Sat, Dec 02, 2023 at 02:23:59PM +0100, Willy Tarreau wrote: > > Hi Alexey, > > > > On Sat, Dec 02, 2023 at 03:45:13PM +0300, Alexey Dobriyan wrote: > > > Just jump into _start_c, it is not going to return anyway. > > > > Thanks, but what's upper in the stack there ? > > argc > > (gdb) break _start > (gdb) run > > (gdb) x/20gx $sp > 0x7fffffffdae0: 0x0000000000000004 0x00007fffffffdf33 > 0x7fffffffdaf0: 0x00007fffffffdf49 0x00007fffffffdf4b > 0x7fffffffdb00: 0x00007fffffffdf4d 0x0000000000000000 > 0x7fffffffdb10: 0x00007fffffffdf4f 0x00007fffffffdf70 > 0x7fffffffdb20: 0x00007fffffffdf80 0x00007fffffffdfce > > (gdb) x/s 0x00007fffffffdf33 > 0x7fffffffdf33: "/home/ad/s-test/a.out" > > > I'm trying to make sure > > that if _start_c returns we don't get a random behavior. > > Yes, it should segfault executing from very small address. > I tested with > > .intel_syntax noprefix > .globl _start > _start: > ret > mov eax, 231 > xor edi, edi > syscall Well, this could possibly be acceptable then but the ABI also says that we need rsp to be 16-byte aligned before the call, so it's supposed to be 8 on top of this, so this would actually require more code to maintain this guarantee, since a sub rsp,8 is longer than just the hlt we're saving. > > If we get a > > systematic crash (e.g. 0 always there) that's fine, what would be > > annoying would be random infinite loops etc. In the psABI description > > (table 3.9) I'm seeing "undefined" before argc, which I don't find > > much appealing. > > > > > Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> > > > --- > > > > > > Also, kernel clears all registers before starting process, > > > I'm not sure why > > > > > > xor ebp, ebp > > > > > > was added. > > > > Hmmm psABI says: > > > > Only the registers listed below have specied values at process entry: > > > > %rbp The content of this register is unspecied at process initialization > > time, but the user code should mark the deepest stack frame by setting > > the frame pointer to zero. > > > > %rsp The stack pointer holds the address of the byte with lowest address > > which is part of the stack. It is guaranteed to be 16-byte aligned at > > process entry. > > > > %rdx a function pointer that the application should register with atexit (BA_OS). > > > > Thus apparently it's documented as being our job to clear it :-/ > > I meant, ELF loader clears all registers except rsp and aligns the stack to 16 bytes. > There were problems with stack aligning, but registers, I think, were always zeroed. But there's a strong difference between what's observed and what's specified. If you get the x86_64 ABI spec to reflect this, it becomes the standard and we can rely on it. Otherwise the standard remains what is documented, and what is implemented may change while remaining within the specs above. Willy
--- a/tools/include/nolibc/arch-x86_64.h +++ b/tools/include/nolibc/arch-x86_64.h @@ -167,8 +167,7 @@ void __attribute__((weak, noreturn, optimize("Os", "omit-frame-pointer"))) __no_ "xor %ebp, %ebp\n" /* zero the stack frame */ "mov %rsp, %rdi\n" /* save stack pointer to %rdi, as arg1 of _start_c */ "and $-16, %rsp\n" /* %rsp must be 16-byte aligned before call */ - "call _start_c\n" /* transfer to c runtime */ - "hlt\n" /* ensure it does not return */ + "jmp _start_c\n" /* transfer to c runtime */ ); __builtin_unreachable(); }