From patchwork Thu Dec 8 14:34:34 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Polacek X-Patchwork-Id: 1713766 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=eti48cPg; dkim-atps=neutral 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 ECDSA (P-384) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4NScBJ3RWtz23p1 for ; Fri, 9 Dec 2022 01:35:02 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9CC29395BC39 for ; Thu, 8 Dec 2022 14:35:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9CC29395BC39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1670510100; bh=Ncpgujpav/VZ1bjrU+ce5nl3xXsh+zjmK/BrpIWXE+o=; h=Date:To:Cc:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=eti48cPgmOglYiVwu83JU/pYRYXKI2qXOgWE9gAZnKISRNgzIZc04HujEfzUScU/t fqBVeZ32270e779wP5FsicjjSbsJKt3KsrXL8zOALLGL02ma/rVaI/0MSbb1CsJE1B EktoqeWixPgzedprWEGT/fYLCSOdBh0JqBfHDGLA= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org 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 55A85395B44E for ; Thu, 8 Dec 2022 14:34:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 55A85395B44E Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-130-tzNeQuNxOfahhZt0cxGV_A-1; Thu, 08 Dec 2022 09:34:37 -0500 X-MC-Unique: tzNeQuNxOfahhZt0cxGV_A-1 Received: by mail-qv1-f71.google.com with SMTP id a15-20020ad441cf000000b004c79ef7689aso1518222qvq.14 for ; Thu, 08 Dec 2022 06:34:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Ncpgujpav/VZ1bjrU+ce5nl3xXsh+zjmK/BrpIWXE+o=; b=IRqnYvfBRxhRceoghov99OR7MM1tFeedvb7buJAdRIGWQOIW6mSZLobaeTKtqH7paI 5lJfPOlFP4vjeOJN/71wiAY1+FOF+W0k0J6EpEMPpDI20Wy4NJrjQIZkkSzwZE6Q43PL 4ZU4YgHGKV0egp3OMiQumdraIp8ZTcL7KCVRHenwPQ3QWMH6R6D33EPETRQ0vH8EJP0G q7rA7Uq0ZQm1MmMqy2v6YQtpf8MZl6Dr5GNW2szjgU6O+N9iOWWmWP+PFGE1Cd+oJcN/ venhX78ZqfNC3gX6LuSvkC3BeyWgEtT6O19TdnPlnk2oNr1/BZGuCxW9Rf0Ho78QfraR Lnqg== X-Gm-Message-State: ANoB5pkX2ZYSnv3h4JNuLrOd27T+y+ByHuO3dGPQk7E0R/z4cUAb/KlS C8dEp+fJrMrz15YhPd7k++PUXDMU7YU5zSg8WnaAqOzCFBLVAw7OWsn5U5LmDcY9eKAzjFNcWoJ 28x1ImZtxMwUxnuFB9A== X-Received: by 2002:ac8:6705:0:b0:3a7:b44d:bd56 with SMTP id e5-20020ac86705000000b003a7b44dbd56mr16539010qtp.464.1670510077382; Thu, 08 Dec 2022 06:34:37 -0800 (PST) X-Google-Smtp-Source: AA0mqf6PQbBfqz1nZCS441BQLi0i7YwbHiHKtFAydBujfYOEavbnv6uy+7dsPrdI14XtcduAWe+4gw== X-Received: by 2002:ac8:6705:0:b0:3a7:b44d:bd56 with SMTP id e5-20020ac86705000000b003a7b44dbd56mr16539005qtp.464.1670510077115; Thu, 08 Dec 2022 06:34:37 -0800 (PST) Received: from redhat.com (2603-7000-9500-2e39-0000-0000-0000-1db4.res6.spectrum.com. [2603:7000:9500:2e39::1db4]) by smtp.gmail.com with ESMTPSA id l25-20020ac81499000000b003a50b9f099esm14919080qtj.12.2022.12.08.06.34.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Dec 2022 06:34:36 -0800 (PST) Date: Thu, 8 Dec 2022 09:34:34 -0500 To: Jakub Jelinek Cc: Florian Weimer , Marek Polacek via Gcc-patches Subject: [PATCH v2] docs: Suggest options to improve ASAN stack traces Message-ID: References: <20221207203409.104322-1-polacek@redhat.com> <87fsdqjr15.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.2.7 (2022-08-07) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Marek Polacek via Gcc-patches From: Marek Polacek Reply-To: Marek Polacek Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" On Thu, Dec 08, 2022 at 03:28:13PM +0100, Jakub Jelinek wrote: > On Thu, Dec 08, 2022 at 09:11:54AM -0500, Marek Polacek via Gcc-patches wrote: > > On Thu, Dec 08, 2022 at 08:25:26AM +0100, Florian Weimer wrote: > > > * Marek Polacek via Gcc-patches: > > > > > > > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > > > > index 726392409b6..2de14466dd3 100644 > > > > --- a/gcc/doc/invoke.texi > > > > +++ b/gcc/doc/invoke.texi > > > > @@ -16510,6 +16510,14 @@ The option cannot be combined with @option{-fsanitize=thread} or > > > > @option{-fsanitize=hwaddress}. Note that the only target > > > > @option{-fsanitize=hwaddress} is currently supported on is AArch64. > > > > > > > > +To get more accurate stack traces, it is possible to use options such as > > > > +@option{-O} (which, for instance, prevents most function inlining), > > > > +@option{-fno-optimize-sibling-calls} (which prevents optimizing sibling > > > > +and tail recursive calls), or @option{-fno-ipa-icf} (which disables Identical > > > > +Code Folding for functions and read-only variables). Since multiple runs > > > > +of the program may yield backtraces with different addresses due to ASLR, > > > > +it may be desirable to turn off ASLR: @samp{setarch `uname -m` -R ./prog}. > > > > > > What about -fasynchronous-unwind-tables? It should help if ASAN ever > > > reports stray segmentation faults. Whether it also helps in general > > > depends on whether ASAN maintains ABI around its instrumentation. > > > > I'm not sure. Someone else will have to decide if we want to mention > > that option as well. > > -fasynchronous-unwind-tables is on by default on many targets, so I wouldn't > mention it: > grep asynchronous_unwind_tables common/*/*/* config/*/* > common/config/aarch64/aarch64-common.cc: { OPT_LEVELS_ALL, OPT_fasynchronous_unwind_tables, NULL, 1 }, > common/config/i386/i386-common.cc: opts->x_flag_asynchronous_unwind_tables = 2; > common/config/loongarch/loongarch-common.cc: { OPT_LEVELS_ALL, OPT_fasynchronous_unwind_tables, NULL, 1 }, > common/config/rs6000/rs6000-common.cc: opts->x_flag_asynchronous_unwind_tables = 1; > common/config/s390/s390-common.cc: opts->x_flag_asynchronous_unwind_tables = 1; > config/i386/i386-options.cc: if (opts->x_flag_asynchronous_unwind_tables == 2) > config/i386/i386-options.cc: opts->x_flag_asynchronous_unwind_tables = !USE_IX86_FRAME_POINTER; > config/mips/mips.cc: && !global_options_set.x_flag_asynchronous_unwind_tables) > config/mips/mips.cc: flag_asynchronous_unwind_tables = 1; > config/rs6000/rs6000.cc: && !OPTION_SET_P (flag_asynchronous_unwind_tables)) > config/rs6000/rs6000.cc: flag_asynchronous_unwind_tables = 1; > > On the other side, the @samp{setarch `uname -m` -R ./prog} suggestion is > very Linux specific, so if we mention it at all, it should mention that > "e.g. on Linux through ..." or something similar. > I also wouldn't mention the "and read-only variables" part, that is > irrelevant for stack traces. Thanks, updated patch here. I've also expanded the ASLR acronym. Ok? -- >8 -- I got a complaint that while Clang docs suggest options that improve the quality of the backtraces ASAN prints (cf. ), our docs don't say anything to that effect. This patch amends that with a new paragraph. (It deliberately doesn't mention -fno-omit-frame-pointer.) gcc/ChangeLog: * doc/invoke.texi (-fsanitize=address): Suggest options to improve stack traces. --- gcc/doc/invoke.texi | 9 +++++++++ 1 file changed, 9 insertions(+) base-commit: d9f9d5d30feb33c359955d7030cc6be50ef6dc0a diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 726392409b6..1641efecf18 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -16510,6 +16510,15 @@ The option cannot be combined with @option{-fsanitize=thread} or @option{-fsanitize=hwaddress}. Note that the only target @option{-fsanitize=hwaddress} is currently supported on is AArch64. +To get more accurate stack traces, it is possible to use options such as +@option{-O} (which, for instance, prevents most function inlining), +@option{-fno-optimize-sibling-calls} (which prevents optimizing sibling +and tail recursive calls), or @option{-fno-ipa-icf} (which disables Identical +Code Folding for functions). Since multiple runs of the program may yield +backtraces with different addresses due to ASLR (Address Space Layout +Randomization), it may be desirable to turn ASLR off. On Linux, this can be +achieved with @samp{setarch `uname -m` -R ./prog}. + @item -fsanitize=kernel-address @opindex fsanitize=kernel-address Enable AddressSanitizer for Linux kernel.