Enable -funwind-tables by default on Power PC (Bugzilla Bug 32611)

Hi all,

I’ve been looking at this bug:

The bug involves a function that is specified as not throwing anything but in reality it does throw.

void func() throw() {
throw 100;

When this code is run we should see a call to __cxa_call_unexpected but we do not. The reason is because the function does not generate the unwind tables.
func() is marked with the nounwind attribute as is expected due to the fact the user has told us it does not throw anything. However, that attribute also blocks the generation of the unwind tables which are required for the proper functioning of the call to unexpected. The solution is to also use the attribute uwtable which forces the generation of the unwind tables.

Checking how this works on x86 I realised that this works because -funwind-tables is on by default for x86 and therefore adds the uwtable attribute to almost all of the functions being compiled.
I’ve added a patch
that does the same thing for PowerPC as is done on x86 and it fixes the bug.

However, I feel like this solution adds a function attribute to a whole set of functions where it is not needed. The vast majority of functions that will now receive the uwtable attribute don’t actually need it.
Has anyone encountered an issue where a function marked as nounwind actually requires unwind tables? Does anyone know of a better solution for this?

Thank you,

I think not generating unwind tables for nounwind functions with EH personalities is a bug.

It’s true that the program never unwinds out of func, but it internally catches all possibly unwinding exceptions and calls __cxa_call_unexpected. That requires .cfi directives.

It looks like this bug applies to both ppc64 and x86_64. It must be in common prologue emission code, or all the targets have the same bug. We shouldn’t need the uwtable attribute to get this case right.

In that case this may be a bug on all targets.

/// True if this function needs an unwind table.
bool needsUnwindTableEntry() const {
return hasUWTable() || !doesNotThrow();

This is part of the target independent Function class. We determine if we need an unwind table entry by checking that we either have the uwtable attribute that I mentioned or that we do not have nounwind. What you are saying is that in this case we should also check to see if the function has an EH personality. Does that sound reasonable?