-fno-unwind-tables -fno-asynchronous-unwind-tables versus debugging

[Ian Lance Taylor]

On Thu, Oct 6, 2016 at 10:25 AM,  <waltdnes@waltdnes.org> wrote:
>   A few years ago on the Busybox list I stumbled over...
> http://lists.busybox.net/pipermail/busybox/2012-September/078326.html
> http://lists.busybox.net/pipermail/busybox/2012-September/078331.html
>
> ...where "-fno-unwind-tables -fno-asynchronous-unwind-tables" CFLAGS
> were shown to reduce the filesize of builds.  The Busybox people are
> building for constrained environments, so this is very important to
> them.  I include those flags in my Gentoo linux config.
>
>   I'm manually building and running the beta for the next version of
> Pale Moon (linux).  A build without the flags produces a 43,262,332 byte
> tarball.  With the flags, it's 40,528,597 bytes; approximately 2.7
> megabytes smaller.  I've suggested to the developers that they use these
> flags when building Pale Moon, but they have concerns about impacts on
> debugging.
>
>   So my question is whether or not the flags
> "-fno-unwind-tables -fno-asynchronous-unwind-tables" make debugging
> harder.  Has anything changed in that area in the past 4 years?

For typical use those options will not affect debugging.

Using those options will in some cases make it harder for the debugger
to give you a good backtrace when a signal occurs.

(And of course using those options means that C++ exceptions will not
work correctly, and if you are using glibc the pthread_cancel function
may not work correctly.)

Ian