This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Don't set DECL_IGNORED_P on a cdtor function


> 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.

Agreed.

> 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.

Your comment seems to imply that Geoff's patch should be reverted too. :-)

-- 
Eric Botcazou


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]