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


Geoffrey Keating wrote:

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

> The entire paragraph under 'Eric Botcazou wrote' lists reasons why my
> patch is correct.
> 
> "(a)": well, if you don't have source, tell the debugger that, rather
> than having the debugger associate it with the last line in the previous
> function.

In practice, what happens with your patch?  What file/line information
(if any) is associated with the function?

(I'd rather hope that the debugger was clever enough to associate
regions with no debug information with the nearby ELF (or equivalent)
object file symbols, rather than glomming it onto the previous function,
but that's a separate issue.)

> "(b)": this is what DECL_ARTIFICIAL is for, but it has no effect if
> there's no debug information.

I do see a good argument for generating debug info for these functions:
language-level constructors and destructors may be inlined into them.
So, I guess we'd ideally like to have most of the function be invisible
to the debugger, but we'd like the inlined functions to show up.

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


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