Re: [PATCH] lto: pass through -funwind-tables and -fasynchronous-unwind-tables

[Jakub Jelinek <jakub@redhat.com>]

On Wed, Jan 18, 2023 at 03:14:01PM +0100, Andreas Schwab wrote:
> On Jan 18 2023, Michael Matz wrote:
> 
> > So, it's quite clear that the option merging algorithm related to all this 
> > is somewhat broken, the global (or per function, or whatever) 
> > -funwind-tables option from hello.o doesn't make it correctly into the 
> > output (when -g is there).  Adding -fexception makes it work because then 
> > the functions will have personalities and on LTO-read-in _that_ will 
> > implicitely enable funwind-tables again (which should have been enabled 
> > already by the option-read-in).
> 
> My guess is that flag_unwind_tables is not yet set when .cfi_sections is
> emitted (which is done by dwarf2out_assembly_start before compile starts).

Well, the primary question for PerFunction/Optimization flag is what such
flag means outside of any function.
Because with such flags, it no longer is everything wants unwind tables (or
asynchronous unwind tables), but perhaps some functions want that and others
don't.
So, do we for .cfi_sections want to know whether at least one of the
functions in the TU (or partition for lto1) wants unwind tables /
asynchronous unwind tables, or whether all of them do, something else?

That isn't specific to LTO btw, one can compile say:
-g -O2 -fasynchronous-unwind-tables -funwind-tables
__attribute__((optimize ("no-asynchronous-unwind-tables,no-unwind-tables"))) int foo (int x) { return x; }
__attribute__((optimize ("no-asynchronous-unwind-tables,no-unwind-tables"))) int bar (int x) { return x; }
or
-g -O2 -fno-asynchronous-unwind-tables -fno-unwind-tables
__attribute__((optimize ("asynchronous-unwind-tables,unwind-tables"))) int foo (int x) { return x; }
__attribute__((optimize ("asynchronous-unwind-tables,unwind-tables"))) int bar (int x) { return x; }
Now, for non-LTO what you get in flag_asynchronous_unwind_tables or
flag_unwind_tables when cfun is NULL is I think whatever has been
set on the command line (or defaulted), which doesn't need to match
any of the emitted functions.
For LTO we currently get there just whatever has been defaulted.
Neither of that will always match all the states of all the functions.

	Jakub