S/390: Default to -fasynchronous-unwind-tables

S/390: Default to -fasynchronous-unwind-tables

[Ulrich Weigand]

Hello,

this switches on the DWARF-2 unwind data for all functions by default.

Thanks to Jan Hubicka for pointing out the correct way to do so.

Bootstrapped/regtested on s390-ibm-linux and s390x-ibm-linux.

(Note: a not-yet-published patch to gdb is necessary to actually exploit
the DWARF-2 data for backtraces on s390.)


      * config/s390/s390.c (optimization_options): Set
      flag_asynchronous_unwind_tables to 1 by default.

Index: gcc/config/s390/s390.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/s390/s390.c,v
retrieving revision 1.67
diff -c -p -r1.67 s390.c
*** gcc/config/s390/s390.c    4 Nov 2002 19:04:46 -0000     1.67
--- gcc/config/s390/s390.c    15 Nov 2002 14:17:28 -0000
*************** optimization_options (level, size)
*** 816,821 ****
--- 816,825 ----
  {
    /* ??? There are apparently still problems with -fcaller-saves.  */
    flag_caller_saves = 0;
+
+   /* By default, always emit DWARF-2 unwind info.  This allows debugging
+      without maintaining a stack frame back-chain.  */
+   flag_asynchronous_unwind_tables = 1;
  }

  void


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com

Re: S/390: Default to -fasynchronous-unwind-tables

[Daniel Jacobowitz]

On Fri, Nov 15, 2002 at 06:05:35PM +0100, Ulrich Weigand wrote:
> Hello,
> 
> this switches on the DWARF-2 unwind data for all functions by default.
> 
> Thanks to Jan Hubicka for pointing out the correct way to do so.
> 
> Bootstrapped/regtested on s390-ibm-linux and s390x-ibm-linux.
> 
> (Note: a not-yet-published patch to gdb is necessary to actually exploit
> the DWARF-2 data for backtraces on s390.)

Should we be thinking about doing this on more architectures?  It would
be nice to use this in preference to the terrifying MIPS-specific
unwinder, for instance...

How bad is the space penalty, and is there a way to mark EH tables as
removable if they're only needed for debugging (vs. for -fexceptions)?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: S/390: Default to -fasynchronous-unwind-tables

[Jakub Jelinek]

On Fri, Nov 15, 2002 at 06:05:35PM +0100, Ulrich Weigand wrote:
> Hello,
> 
> this switches on the DWARF-2 unwind data for all functions by default.
> 
> Thanks to Jan Hubicka for pointing out the correct way to do so.
> 
> Bootstrapped/regtested on s390-ibm-linux and s390x-ibm-linux.
> 
> (Note: a not-yet-published patch to gdb is necessary to actually exploit
> the DWARF-2 data for backtraces on s390.)

Is debugging the only reason for this change?
If yes, shouldn't only .debug_frame section be emitted (and not .eh_frame
section) if -fexceptions is not requested?

	Jakub

Re: S/390: Default to -fasynchronous-unwind-tables

[Jan Hubicka]

> On Fri, Nov 15, 2002 at 06:05:35PM +0100, Ulrich Weigand wrote:
> > Hello,
> > 
> > this switches on the DWARF-2 unwind data for all functions by default.
> > 
> > Thanks to Jan Hubicka for pointing out the correct way to do so.
> > 
> > Bootstrapped/regtested on s390-ibm-linux and s390x-ibm-linux.
> > 
> > (Note: a not-yet-published patch to gdb is necessary to actually exploit
> > the DWARF-2 data for backtraces on s390.)
> 
> Should we be thinking about doing this on more architectures?  It would
> be nice to use this in preference to the terrifying MIPS-specific
> unwinder, for instance...
I think we first need to update GDB part.  As far as I am informed, the
GDB dwarf code needs some massaging to work on other backends.
I would like to see this enabled for i386 and default to
-fomit-frame-pointer too BTW.
> 
> How bad is the space penalty, and is there a way to mark EH tables as
> removable if they're only needed for debugging (vs. for -fexceptions)?
One should also think about stack unwinding needed for other reasons -
for instance garbage collecting.
I think there is some linker feature to throw away eh section when not
needed tought.

Honza
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

Re: S/390: Default to -fasynchronous-unwind-tables

[Richard Henderson]

On Fri, Nov 15, 2002 at 02:13:10PM -0500, Daniel Jacobowitz wrote:
> Should we be thinking about doing this on more architectures?  It would
> be nice to use this in preference to the terrifying MIPS-specific
> unwinder, for instance...

No.  Nor should it have been done for s390 IMO.  Who cares if
you can't get a backtrace without debug information?

> How bad is the space penalty,

> ... and is there a way to mark EH tables as
> removable if they're only needed for debugging (vs. for -fexceptions)?

Duh, no.  That's what .debug_frame is for -- debugging.


r~

Re: S/390: Default to -fasynchronous-unwind-tables

[Jan Hubicka]

> On Fri, Nov 15, 2002 at 02:13:10PM -0500, Daniel Jacobowitz wrote:
> > Should we be thinking about doing this on more architectures?  It would
> > be nice to use this in preference to the terrifying MIPS-specific
> > unwinder, for instance...
> 
> No.  Nor should it have been done for s390 IMO.  Who cares if
> you can't get a backtrace without debug information?

It is told to be important for garbage collectors used by JITs and
similar tricks.

Honza
> 
> > How bad is the space penalty,
> 
> > ... and is there a way to mark EH tables as
> > removable if they're only needed for debugging (vs. for -fexceptions)?
> 
> Duh, no.  That's what .debug_frame is for -- debugging.
> 
> 
> r~

Re: S/390: Default to -fasynchronous-unwind-tables

[Ulrich Weigand]

Jakub Jelinek wrote:

>But without .symtab/.strtab the backtraces aren't much useful anyway.
>Which is not much different from making sure .debug_frame stays.

Not really.  Even without symbolic names, a backtrace is still useful.
Also, you can build those parts you are interested in with debug info,
so a backtrace will show *those* symbols at least, even if you actually
crash in a system library.

But without backtrace, you can basically do nothing.

>> While you could certainly say that they should just build the app
>> with -g1, this doesn't help if the crash happens in a library routine.
>> One solution would be to build all system libraries also with -g1,
>> which we had considered, but this has the disadvantage that 'strip'
>> removes the information (and the usual RPM build process strips all
>> binaries and libraries) ...
>
>This is changing.

Well, that would also be an option.  But I don't quite see why this
would be an improvement over using -fasynchronous-unwind-tables,
seeing as -g1 takes significantly more space, and additionally duplicates
.eh_frame info where that is needed anyway ...


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com

Re: S/390: Default to -fasynchronous-unwind-tables

[Jakub Jelinek]

On Wed, Nov 20, 2002 at 06:02:29PM +0100, Ulrich Weigand wrote:
> 
> Richard Henderson wrote:
> 
> >No.  Nor should it have been done for s390 IMO.  Who cares if
> >you can't get a backtrace without debug information?
> 
> Well, it is a basic servicability requirement from many application
> vendors to be able to get a backtrace when a crash happens.  This
> in particular includes the case where crashes happen while executing
> any library routine.

But without .symtab/.strtab the backtraces aren't much useful anyway.
Which is not much different from making sure .debug_frame stays.

> While you could certainly say that they should just build the app
> with -g1, this doesn't help if the crash happens in a library routine.
> One solution would be to build all system libraries also with -g1,
> which we had considered, but this has the disadvantage that 'strip'
> removes the information (and the usual RPM build process strips all
> binaries and libraries) ...

This is changing.

	Jakub

Re: S/390: Default to -fasynchronous-unwind-tables

[Ulrich Weigand]

Richard Henderson wrote:

>No.  Nor should it have been done for s390 IMO.  Who cares if
>you can't get a backtrace without debug information?

Well, it is a basic servicability requirement from many application
vendors to be able to get a backtrace when a crash happens.  This
in particular includes the case where crashes happen while executing
any library routine.

While you could certainly say that they should just build the app
with -g1, this doesn't help if the crash happens in a library routine.
One solution would be to build all system libraries also with -g1,
which we had considered, but this has the disadvantage that 'strip'
removes the information (and the usual RPM build process strips all
binaries and libraries) ...

B.t.w. we are currently generating *code* maintaining a stack backchain
at run time that is solely needed to generate backtraces -- this is not
like the frame pointer on Intel which has additional uses apart from
enabling backtraces.  The unwind tables allow us to get rid of this
run-time overhead at the expense of somewhat increased space needs,
while still providing the same essential feature: backtraces must be
possible under any circumstances.

In any case, this just changes a default setting.  Whoever really
wants to get rid of the unwind tables can still switch them off.


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com

Re: S/390: Default to -fasynchronous-unwind-tables

[Ulrich Weigand]

Daniel Jacobowitz wrote:

>How bad is the space penalty, and is there a way to mark EH tables as
>removable if they're only needed for debugging (vs. for -fexceptions)?

Space penalty appears to be about 5%.  However, this stuff sits in its
own section, and usually won't be paged in unless touched, so it should
not affect physical memory consumption, just disk space.

If you don't want the data present all the time, you might want to 
use .debug_frame instead of .eh_frame, e.g. by using -g1 instead
of -fasynchronous-unwind-tables.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: S/390: Default to -fasynchronous-unwind-tables

[Ulrich Weigand]

Jakub Jelinek wrote:

>Is debugging the only reason for this change?
>If yes, shouldn't only .debug_frame section be emitted (and not .eh_frame
>section) if -fexceptions is not requested?

Well, we really want this data to be present for all libraries
at any time; if you crash somewhere in a library, you need to
be able to generate a stack backtrace even in production code.

(Note that the goal of this change is to remove the stack 
back-chain at some point in the future.  Once this is done,
there will be *no* way to even generate a stack backtrace
without the DWARF-2 data.  The back-chain is currently
maintained at run-time, which implies a measurable overhead
of about 1-2% SPECint2000 for example.)

.debug_frame has the problem that it is stripped, so that it
won't be in libraries installed via RPM usually; also even -g1
appears to generate more stuff than just .debug_frame; and
finally if we need -fexceptions as well the info would be
duplicated ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de