WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: [Solved] should -fno-asynchronous-unwind-tables be a standard compilation option  (Read 1863 times)

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1378
Information about "-fasynchronous-unwind-tables" gcc flag can be found here. This interesting post says that "-fno-asynchronous-unwind-tables -fno-exceptions" is the "historically common behavior" (which I'm taking to mean that it was only recently that gcc started to enable asynchronous unwind tables by default).

In my own experiments I've noticed that adding "-fno-asynchronous-unwind-tables" to the standard size-optimization flags (such as -Os) results in binaries that are ~15% smaller than when using the same size-optimization flags without it. I have not noticed any ill side effects in my limited tests.

I readily admit that I know very little when it comes to gcc's baroque inner workings. So I have two questions for you smart TCL folks:

1. Could "-fno-asynchronous-unwind-tables" possibly affect normal function, or does it really only decrease bloat (e.g., by removing debug symbols)?

2. Should "-fno-asynchronous-unwind-tables" become one of the standard gcc flags that I use (along with -Os etc.) when creating size-optimized extensions for TCL?
« Last Edit: August 23, 2023, 12:55:46 PM by Rich »

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10992
I think it's safe to use in most normal programs, and would only affect function if compiling a JIT env that uses it (like the Java or C# runtimes, possibly).
The only barriers that can stop you are the ones you create yourself.

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1378
H curaga. Thanks. I'll start using it for my extension submissions then.

curaga, what do you think about compiling Lua interpreter with this option (the standard Lua interpreter, not LuaJIT)?

Offline patrikg

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 684
What version do you use for gcc ??
You could maybe use -Oz, to make it smaller.

Cut from the gcc manual.

-Oz
Optimize aggressively for size rather than speed. This may increase the number of instructions executed if those instructions require fewer bytes to encode. -Oz behaves similarly to -Os including enabling most -O2 optimizations.


Offline CNK

  • Full Member
  • ***
  • Posts: 249
This old GCC mailing list thread relates it to the -fomit-frame-pointer option.

In this post:
Quote
It's a correctness issue. I've been told ommitting the frame pointer
without asynchronous unwind tables is unsafe, and therefore inappropriate
for -Os. A better alternative would be to have -Os require a frame
pointer and thereby omit the unwind tables, as the resulting binary
object files (as measured by CSiBE) would be smaller.

But it seems that -fomit-frame-pointer and -fno-asynchronous-unwind-tables are safe together for normal programs, as Curaga suggests.

It also looks like this behaviour isn't particularly new on x86 and x86_64 (-fasynchronous-unwind-tables default is "enabled" in GCC 4.9.2 on old Debian ("gcc -Q --help=optimizers")). Newer on AARCH64.

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10992
Lua is probably safe with it.
The only barriers that can stop you are the ones you create yourself.

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1378
Hi patrikg. I use gcc version in TC14 x86_64 repo (v12.2.0).

curaga, patrikg, and CNK, thank you very much for the helpful information! Thread may be marked as solved.

Happy hacking!

Online Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11315
Hi GNUser
... Thread may be marked as solved. ...
Done.  :)