This is the mail archive of the
mailing list for the GCC project.
Re: Don't set DECL_IGNORED_P on a cdtor function
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
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
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.
(650) 331-3385 x713