All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhangjin Wu <falcon@tinylab.org>
To: thomas@t-8ch.de
Cc: arnd@arndb.de, falcon@tinylab.org, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org, w@1wt.eu
Subject: Re: [PATCH v3 02/11] tools/nolibc: add new crt.h with _start_c
Date: Sat, 15 Jul 2023 17:23:01 +0800	[thread overview]
Message-ID: <20230715092301.339180-1-falcon@tinylab.org> (raw)
In-Reply-To: <34b21ba5-7b59-4b3b-9ed6-ef9a3a5e06f7@t-8ch.de>

> On 2023-07-14 17:47:23+0800, Zhangjin Wu wrote:
> > > On 2023-07-14 13:58:13+0800, Zhangjin Wu wrote:
> 
> > [..]
> 
> > > I was also not able to reproduce the issue.
> > >
> > 
> > Thanks very much for your 'reproduce' result, It is so weird, just
> > rechecked the toolchain, 13.1.0 from https://mirrors.edge.kernel.org/ is
> > ok, gcc 9, gcc 10.3 not work.
> > 
> > But even in the page of 13.1.0 [1], we still see this line:
> > 
> >     Most optimizations are completely disabled at -O0 or if an -O level is not set on the command line, even if individual optimization flags are specified.
> > 
> > Not sure if "individual optimization flags" also means the optimize()
> > flags in gcc attributes. or the doc is not updated yet?
> > 
> > And further found gcc 11.1.0 is ok, gcc 10.4 still not work, so, gcc
> > 11.1.0 may changed something to let the "individual optimization flags"
> > work with -O0.
> > 
> > We may need to at least document this issue in some files, -O0 is not such a
> > frequently-used option, not sure if we still need -O0 work with the older gcc <
> > 11.1.0 ;-)
> 
> It seems we can avoid the issue by enforcing optimizations for _start:
> 
> diff --git a/tools/include/nolibc/arch-x86_64.h b/tools/include/nolibc/arch-x86_64.h
> index f5614a67f05a..b9d8b8861dc4 100644
> --- a/tools/include/nolibc/arch-x86_64.h
> +++ b/tools/include/nolibc/arch-x86_64.h
> @@ -161,12 +161,9 @@
>   * 2) The deepest stack frame should be zero (the %rbp).
>   *
>   */
> -void __attribute__((weak, noreturn, optimize("omit-frame-pointer"))) __no_stack_protector _start(void)
> +void __attribute__((weak, noreturn, optimize("Os", "omit-frame-pointer"))) __no_stack_protector _start(void)
>

Great, it works and it is minimal enough ;-)

Thanks very much.

> > 
> > Willy, I'm not sure if the issues solved by the commit 7f8548589661
> > ("tools/nolibc: make compiler and assembler agree on the section around
> > _start") still exist after we using _start_c()?
> > 
> > Thomas, because we plan to move the stackprotector init to _start_c(), If using
> > pure assembly _start, we may also not need the __no_stack_protector macro too?
> 
> It would probably not needed anymore in this case.
>

Yeah, but let's reserve it as-is for we have the working
omit-frame-pointer now.

Best regards,
Zhangjin

> Thomas

  reply	other threads:[~2023-07-15  9:23 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-12  9:15 [PATCH v3 00/11] tools/nolibc: shrink arch support Zhangjin Wu
2023-07-12  9:16 ` [PATCH v3 01/11] tools/nolibc: remove the old sys_stat support Zhangjin Wu
2023-07-15  8:59   ` Willy Tarreau
2023-07-15 10:39     ` Zhangjin Wu
2023-07-15 11:45       ` Willy Tarreau
2023-07-12  9:17 ` [PATCH v3 02/11] tools/nolibc: add new crt.h with _start_c Zhangjin Wu
2023-07-12 20:39   ` Thomas Weißschuh
2023-07-13  6:12     ` Zhangjin Wu
2023-07-13  6:23       ` Zhangjin Wu
2023-07-13  6:24       ` Thomas Weißschuh
2023-07-13  6:34       ` Willy Tarreau
2023-07-14  5:58         ` Zhangjin Wu
2023-07-14  6:34           ` Thomas Weißschuh
2023-07-14  9:47             ` Zhangjin Wu
2023-07-15  7:24               ` Thomas Weißschuh
2023-07-15  9:23                 ` Zhangjin Wu [this message]
2023-07-15  9:57           ` Willy Tarreau
2023-07-12  9:18 ` [PATCH v3 03/11] tools/nolibc: arm: shrink _start " Zhangjin Wu
2023-07-12  9:19 ` [PATCH v3 04/11] tools/nolibc: aarch64: " Zhangjin Wu
2023-07-12  9:20 ` [PATCH v3 05/11] tools/nolibc: i386: " Zhangjin Wu
2023-07-12  9:22 ` [PATCH v3 06/11] tools/nolibc: x86_64: " Zhangjin Wu
2023-07-12  9:23 ` [PATCH v3 07/11] tools/nolibc: mips: " Zhangjin Wu
2023-07-12  9:24 ` [PATCH v3 08/11] tools/nolibc: loongarch: " Zhangjin Wu
2023-07-12  9:25 ` [PATCH v3 09/11] tools/nolibc: riscv: " Zhangjin Wu
2023-07-12  9:26 ` [PATCH v3 10/11] tools/nolibc: s390: " Zhangjin Wu
2023-07-12  9:27 ` [PATCH v3 11/11] tools/nolibc: arch-*.h: add missing space after ',' Zhangjin Wu
2023-07-15 10:01 ` [PATCH v3 00/11] tools/nolibc: shrink arch support Willy Tarreau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230715092301.339180-1-falcon@tinylab.org \
    --to=falcon@tinylab.org \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=thomas@t-8ch.de \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.