On 10/05/14 08:57, Daniel Gutson wrote:
On Sun, Oct 5, 2014 at 12:47 PM, Michael Eager <ea...@eagercon.com> wrote:
On 10/05/14 07:27, Daniel Gutson wrote:

Hello,

     this is my first post to this list.

Context: I've been a gdb and gcc maintainer in the past, but I'm not a
DWARF expert, so my post is
from the user's POV.

PROBLEM: ability to break in (all) the global objects' constructors
(that is, before main() is called),
and destructors (after main() ).

As a matter of proof of concept, we've developed a gdb script that is
also nontrivial and imperfect.
FWIW, there were two ways: one implementation-agnostic by regex
finding the ctors of all objects and
adding breakpoints in all of them, then breaking at main, disabling
the former and continuing;
another way was implementation-specific, knowing the internals of the
__static_initialization_and_destruction_0
mechanism. Our proof of concept used the first approach but had a lot of
issues.

So, it would be absolutely trivial if there was a DW_CTOR_CALL /
DW_DTOR_CALL with the address
of the call instruction, so the debugger can break on those calls, and
do a step-into to get into the ctor/dtor body.


I don't think that a special DWARF TAG would be required for this.
You could use DW_TAG_subprogram to describe the ctor/dtor routine,
marked with with DW_AT_artificial.

It's not a solution, because the problem is not identifying the
function (the constructor
in this case), but the CALL to the constructor.
Why? Because the same class could have several global instances, and non-global
(attributes, local) instances.
So what is needed is to identify the invoking places.

If what you want to do is break at all constructors/destructors, I
don't see why you need to break at the calling site.

Can you give an example?

--
Michael Eager    ea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Reply via email to