public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Michael Matz <matz@suse.de>
To: gcc-patches@gcc.gnu.org
Cc: Jakub Jelinek <jakub@redhat.com>, Andreas Schwab <schwab@suse.de>,
	 Richard Biener <richard.guenther@gmail.com>,
	Jan Hubicka <hubicka@ucw.cz>
Subject: Re: [PATCH] lto: pass through -funwind-tables and -fasynchronous-unwind-tables
Date: Wed, 18 Jan 2023 14:03:42 +0000 (UTC)	[thread overview]
Message-ID: <alpine.LSU.2.20.2301181328520.30340@wotan.suse.de> (raw)
In-Reply-To: <mvmtu0oxajh.fsf@suse.de>

On Wed, 18 Jan 2023, Andreas Schwab via Gcc-patches wrote:

> No unwind tables are generated, as if -funwind-tables is ignored.  If
> LTO is disabled, everything works as expected.

On Risc-V btw.  (which, unlike i386,aarch64,s390,rs6000 does not 
effectively enable funwind-tables always via either backend or 
common/config/$arch/ code, which is the reason why the problem can't be 
seen there).  It's an interaction with -g :

The problem (with cross compiler here, but shouldn't matter):

% riscv64-gcc -g -flto -funwind-tables -fPIC -c hello.c
% riscv64-gcc -shared hello.o
% readelf -wF a.out
... empty .eh_frame ...
Contents of the .debug_frame section:
... content ...

Using a compiler for any of the above archs makes this work (working means 
that the unwind info is placed into .eh_frame, _not_ into .debug_frame).  
Not using -g makes it work.  Adding -funwind-tables to the link command 
makes it work.  Adding -fexceptions to the compile command makes it work.  
Not using LTO makes it work.

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

As written initially the other archs are working because they all have 
various ways of essentially setting flag_unwind_tables always:

i386 via common/config/i386/i386-common.cc
   opts->x_flag_asynchronous_unwind_tables = 2;
  config/i386/i386-options.cc
         if (opts->x_flag_asynchronous_unwind_tables == 2)
           opts->x_flag_unwind_tables
             = opts->x_flag_asynchronous_unwind_tables = 1;

rs6000 via common/config/rs6000/rs6000-common.cc
   #ifdef OBJECT_FORMAT_ELF
     opts->x_flag_asynchronous_unwind_tables = 1;
   #endif
  (which ultimately also enabled flag_unwind_tables)

s390 via common/config/s390/s390-common.cc
    opts->x_flag_asynchronous_unwind_tables = 1;

aarch64 via common/config/aarch64/aarch64-common.cc
  #if (TARGET_DEFAULT_ASYNC_UNWIND_TABLES == 1)
    { OPT_LEVELS_ALL, OPT_fasynchronous_unwind_tables, NULL, 1 },
    { OPT_LEVELS_ALL, OPT_funwind_tables, NULL, 1},
  #endif

  (the #define here is set for aarch64*-*-linux* )

So the problem cannot be readily demonstrated on these architectures.  
risc-v has no such code (and doesn't need to).


Ciao,
Michael.

  reply	other threads:[~2023-01-18 14:03 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-18 10:16 Andreas Schwab
2023-01-18 11:05 ` Richard Biener
2023-01-18 11:25   ` Andreas Schwab
2023-01-18 11:31     ` Jakub Jelinek
2023-01-18 12:30       ` Andreas Schwab
2023-01-18 12:35         ` Jakub Jelinek
2023-01-18 12:39           ` Andreas Schwab
2023-01-18 12:47             ` Jakub Jelinek
2023-01-18 13:00               ` Andreas Schwab
2023-01-18 14:03                 ` Michael Matz [this message]
2023-01-18 14:14                   ` Andreas Schwab
2023-01-18 14:25                     ` Jakub Jelinek
2023-01-18 15:11                       ` Andreas Schwab
2023-01-18 14:27                   ` Jakub Jelinek
2023-01-18 15:09                     ` Andreas Schwab
2023-01-18 15:11                       ` Jakub Jelinek
2023-01-18 15:16                         ` Michael Matz
2023-01-18 15:19                           ` Jakub Jelinek
2023-01-18 15:32                             ` Michael Matz
2023-01-18 16:09                               ` Andreas Schwab
2023-01-18 16:25                                 ` Jan Hubicka
2023-01-18 16:28                                   ` Jakub Jelinek
2023-01-18 15:07                 ` Jan Hubicka
2023-01-19  7:14                   ` Richard Biener
2023-01-18 13:36               ` Andreas Schwab
2023-01-25 13:16 ` Richard Biener
2023-01-25 13:50   ` Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LSU.2.20.2301181328520.30340@wotan.suse.de \
    --to=matz@suse.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=jakub@redhat.com \
    --cc=richard.guenther@gmail.com \
    --cc=schwab@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).