* [PATCH] docs: Suggest options to improve ASAN stack traces @ 2022-12-07 20:34 Marek Polacek 2022-12-08 7:25 ` Florian Weimer 0 siblings, 1 reply; 8+ messages in thread From: Marek Polacek @ 2022-12-07 20:34 UTC (permalink / raw) To: GCC Patches I got a complaint that while Clang docs suggest options that improve the quality of the backtraces ASAN prints (cf. <https://clang.llvm.org/docs/AddressSanitizer.html#usage>), 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 | 8 ++++++++ 1 file changed, 8 insertions(+) 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}. + @item -fsanitize=kernel-address @opindex fsanitize=kernel-address Enable AddressSanitizer for Linux kernel. base-commit: 3ad0f470c16d5528a5283060b007f8b419c33c92 -- 2.38.1 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] docs: Suggest options to improve ASAN stack traces 2022-12-07 20:34 [PATCH] docs: Suggest options to improve ASAN stack traces Marek Polacek @ 2022-12-08 7:25 ` Florian Weimer 2022-12-08 14:11 ` Marek Polacek 0 siblings, 1 reply; 8+ messages in thread From: Florian Weimer @ 2022-12-08 7:25 UTC (permalink / raw) To: Marek Polacek via Gcc-patches; +Cc: Marek Polacek * 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. Thanks, Florian ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] docs: Suggest options to improve ASAN stack traces 2022-12-08 7:25 ` Florian Weimer @ 2022-12-08 14:11 ` Marek Polacek 2022-12-08 14:28 ` Jakub Jelinek 0 siblings, 1 reply; 8+ messages in thread From: Marek Polacek @ 2022-12-08 14:11 UTC (permalink / raw) To: Florian Weimer; +Cc: Marek Polacek via Gcc-patches 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. Marek ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] docs: Suggest options to improve ASAN stack traces 2022-12-08 14:11 ` Marek Polacek @ 2022-12-08 14:28 ` Jakub Jelinek 2022-12-08 14:34 ` [PATCH v2] " Marek Polacek 0 siblings, 1 reply; 8+ messages in thread From: Jakub Jelinek @ 2022-12-08 14:28 UTC (permalink / raw) To: Marek Polacek; +Cc: Florian Weimer, Marek Polacek via Gcc-patches 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. Jakub ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2] docs: Suggest options to improve ASAN stack traces 2022-12-08 14:28 ` Jakub Jelinek @ 2022-12-08 14:34 ` Marek Polacek 2022-12-08 15:00 ` Jakub Jelinek 0 siblings, 1 reply; 8+ messages in thread From: Marek Polacek @ 2022-12-08 14:34 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Florian Weimer, Marek Polacek via 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. <https://clang.llvm.org/docs/AddressSanitizer.html#usage>), 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(+) 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. base-commit: d9f9d5d30feb33c359955d7030cc6be50ef6dc0a -- 2.38.1 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] docs: Suggest options to improve ASAN stack traces 2022-12-08 14:34 ` [PATCH v2] " Marek Polacek @ 2022-12-08 15:00 ` Jakub Jelinek 2022-12-08 22:56 ` [PATCH v3] " Marek Polacek 0 siblings, 1 reply; 8+ messages in thread From: Jakub Jelinek @ 2022-12-08 15:00 UTC (permalink / raw) To: Marek Polacek; +Cc: Florian Weimer, Marek Polacek via Gcc-patches On Thu, Dec 08, 2022 at 09:34:34AM -0500, Marek Polacek wrote: > I got a complaint that while Clang docs suggest options that improve > the quality of the backtraces ASAN prints (cf. > <https://clang.llvm.org/docs/AddressSanitizer.html#usage>), 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(+) > > 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), Still not sure about this part. For one, I wonder if we shouldn't recommend -O0, -O1 or -Og instead of just one of them, and I'm also not sure how much function inlining is prevented with -O1. always_inline functions are certainly inlined even at -O0 or -Og (at least when called directly), -O1 adds { OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_finline_functions_called_once, NULL, 1 }, to that, -O2 adds { OPT_LEVELS_2_PLUS, OPT_findirect_inlining, NULL, 1 }, { OPT_LEVELS_2_PLUS, OPT_finline_small_functions, NULL, 1 }, { OPT_LEVELS_2_PLUS, OPT_fpartial_inlining, NULL, 1 }, { OPT_LEVELS_2_PLUS, OPT_finline_functions, NULL, 1 }, and -O3 further bumps some parameters: { OPT_LEVELS_3_PLUS, OPT__param_max_inline_insns_auto_, NULL, 30 }, { OPT_LEVELS_3_PLUS, OPT__param_early_inlining_insns_, NULL, 14 }, { OPT_LEVELS_3_PLUS, OPT__param_inline_heuristics_hint_percent_, NULL, 600 }, { OPT_LEVELS_3_PLUS, OPT__param_inline_min_speedup_, NULL, 15 }, { OPT_LEVELS_3_PLUS, OPT__param_max_inline_insns_single_, NULL, 200 }, > +@option{-fno-optimize-sibling-calls} (which prevents optimizing sibling -fno-optimize-sibling-calls is the default for -O0/-O1/-Og; dunno if we want to reiterate it. > +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. Jakub ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v3] docs: Suggest options to improve ASAN stack traces 2022-12-08 15:00 ` Jakub Jelinek @ 2022-12-08 22:56 ` Marek Polacek 2022-12-08 23:11 ` Jakub Jelinek 0 siblings, 1 reply; 8+ messages in thread From: Marek Polacek @ 2022-12-08 22:56 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Florian Weimer, Marek Polacek via Gcc-patches On Thu, Dec 08, 2022 at 04:00:15PM +0100, Jakub Jelinek wrote: > On Thu, Dec 08, 2022 at 09:34:34AM -0500, Marek Polacek wrote: > > I got a complaint that while Clang docs suggest options that improve > > the quality of the backtraces ASAN prints (cf. > > <https://clang.llvm.org/docs/AddressSanitizer.html#usage>), 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(+) > > > > 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), > > Still not sure about this part. For one, I wonder if we shouldn't > recommend -O0, -O1 or -Og instead of just one of them, and I'm also not sure > how much function inlining is prevented with -O1. Right, that's why I put "most" in there. But I think we should mention -O0 and -Og as well. > always_inline functions are certainly inlined even at -O0 or -Og (at least > when called directly), -O1 adds > { OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_finline_functions_called_once, NULL, 1 }, > to that, -O2 adds > { OPT_LEVELS_2_PLUS, OPT_findirect_inlining, NULL, 1 }, > { OPT_LEVELS_2_PLUS, OPT_finline_small_functions, NULL, 1 }, > { OPT_LEVELS_2_PLUS, OPT_fpartial_inlining, NULL, 1 }, > { OPT_LEVELS_2_PLUS, OPT_finline_functions, NULL, 1 }, > and -O3 further bumps some parameters: > { OPT_LEVELS_3_PLUS, OPT__param_max_inline_insns_auto_, NULL, 30 }, > { OPT_LEVELS_3_PLUS, OPT__param_early_inlining_insns_, NULL, 14 }, > { OPT_LEVELS_3_PLUS, OPT__param_inline_heuristics_hint_percent_, NULL, 600 }, > { OPT_LEVELS_3_PLUS, OPT__param_inline_min_speedup_, NULL, 15 }, > { OPT_LEVELS_3_PLUS, OPT__param_max_inline_insns_single_, NULL, 200 }, > > > +@option{-fno-optimize-sibling-calls} (which prevents optimizing sibling > > -fno-optimize-sibling-calls is the default for -O0/-O1/-Og; dunno if we > want to reiterate it. Can't hurt. Here's an updated patch. -- >8 -- I got a complaint that while Clang docs suggest options that improve the quality of the backtraces ASAN prints (cf. <https://clang.llvm.org/docs/AddressSanitizer.html#usage>), 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 | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 726392409b6..3f2512ce16a 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -16510,6 +16510,16 @@ 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{-O0}, @option{-O1}, or @option{-Og} (which, for instance, prevent +most function inlining), @option{-fno-optimize-sibling-calls} (which prevents +optimizing sibling and tail recursive calls; this option is implicit for +@option{-O0}, @option{-O1}, or @option{-Og}), 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. base-commit: 3a9f6d5a8ee490adf9a18f93feaf86542642be7d -- 2.38.1 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3] docs: Suggest options to improve ASAN stack traces 2022-12-08 22:56 ` [PATCH v3] " Marek Polacek @ 2022-12-08 23:11 ` Jakub Jelinek 0 siblings, 0 replies; 8+ messages in thread From: Jakub Jelinek @ 2022-12-08 23:11 UTC (permalink / raw) To: Marek Polacek; +Cc: Florian Weimer, Marek Polacek via Gcc-patches On Thu, Dec 08, 2022 at 05:56:41PM -0500, Marek Polacek wrote: > Can't hurt. Here's an updated patch. > > -- >8 -- > I got a complaint that while Clang docs suggest options that improve > the quality of the backtraces ASAN prints (cf. > <https://clang.llvm.org/docs/AddressSanitizer.html#usage>), 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. Ok, thanks. > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > index 726392409b6..3f2512ce16a 100644 > --- a/gcc/doc/invoke.texi > +++ b/gcc/doc/invoke.texi > @@ -16510,6 +16510,16 @@ 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{-O0}, @option{-O1}, or @option{-Og} (which, for instance, prevent > +most function inlining), @option{-fno-optimize-sibling-calls} (which prevents > +optimizing sibling and tail recursive calls; this option is implicit for > +@option{-O0}, @option{-O1}, or @option{-Og}), 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. Jakub ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-12-08 23:11 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-12-07 20:34 [PATCH] docs: Suggest options to improve ASAN stack traces Marek Polacek 2022-12-08 7:25 ` Florian Weimer 2022-12-08 14:11 ` Marek Polacek 2022-12-08 14:28 ` Jakub Jelinek 2022-12-08 14:34 ` [PATCH v2] " Marek Polacek 2022-12-08 15:00 ` Jakub Jelinek 2022-12-08 22:56 ` [PATCH v3] " Marek Polacek 2022-12-08 23:11 ` Jakub Jelinek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).