[Solved] should -fno-asynchronous-unwind-tables be a standard compilation option

[GNUser]

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?

[curaga]

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).

[GNUser]

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)?

[patrikg]

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.

[CNK]

This old GCC mailing list thread relates it to the -fomit-frame-pointer option.

In this post:

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.

[curaga]

Lua is probably safe with it.

[GNUser]

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!

[Rich]

Hi GNUser

... Thread may be marked as solved. ...

Done.