Re: Don't set DECL_IGNORED_P on a cdtor function

[Mark Mitchell <mark at codesourcery dot com>]

Eric Botcazou wrote:
>> However, given the awkward variability of its effects depending on the
>> target, I agree that it's probably better to revert the change.  Will do
>> shortly.
> 
> Done. 

So, I understand correctly, we're now going to again emit .debug_frame
for DECL_IGNORED_P functions.  That seems good to me, as it helps us
display unwind information through such functions.  I think that's a
strong argument that we should always emit .debug_frame, independent of
whether a function is ignored/artificial.

Geoff's original comment was:

> DECL_IGNORED_P shouldn't be set on any function which the user might
> want to set a breakpoint in, or which might appear in a stack
> backtrace, or which might crash.

There are 3 parts to the comment:

1. Setting breakpoints
2. Backtraces
3. Crashing

Eric's patch solves (2).

I don't think (1) or (3) are sufficient reasons to avoid setting
DECL_IGNORED_P.  Almost all functions might crash (e.g., by extending
the stack beyond the allocated maximum stack size) and *some* users
might want to set breakpoints anywhere.  (Of course, they can always set
a breakpoint by PC or by object-file symbol name anyhow.)

The key issues are that (a) we have no source for these
compiler-generated functions, and (b) they don't correspond to anything
in the source program.  If I say "step" off the end of a C++ "main", I
don't want to end up in one of these functions; I want to end up in the
first C++ destructor being called by them.  That's the C++ view of the
world; these cdtor functions are just implementation details.

So, I think we should consider the issue closed, with Eric's patch.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713