public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Daniel Berlin <dberlin@dberlin.org>
To: Michael Elizabeth Chastain <mec@shout.net>
Cc: drow@mvista.com, pkoning@equallogic.com, carlton@bactrian.org,
	gdb@sources.redhat.com
Subject: Re: breakpoints in constructors
Date: Wed, 30 Apr 2003 05:20:00 -0000	[thread overview]
Message-ID: <662F2E4E-7ACB-11D7-8FE3-000A95A34564@dberlin.org> (raw)
In-Reply-To: <200304300436.h3U4aRGX025659@duracef.shout.net>


On Wednesday, April 30, 2003, at 12:36  AM, Michael Elizabeth Chastain 
wrote:

> Can I de-lurk for a minute?
>
> gcc 2.95.3 had a single object code function for each constructor,
> with a hidden flag to indicate its "in-charge-ness".  I always thought
> that was much nicer for debugging.
>
> But gcc 3.X's multi-object-code implementation is mandated by the
> multi-vendor ABI, which will make it harder.

No it isn't.
It's not required multi-object-code, it's only required that it does 
the right thing when called with a certain name  (not the same at all, 
since one can  just make up the symbols for the constructors that start 
at the right points in the "one object code constructor" function, 
without even having to make stub functions with gotos in them. Just 
multiple symbol names and one object code).

One can also have "one object code implementation" with labels and use 
gotos and stub functions if you like.
Or one can have three copies of the object code.

It's not like even with three copies, that this is a laborious task.
It just means that you set multiple breakpoints.

One way is to make one "visible" breakpoint and 2 "hidden" breakpoints.
This is a bit ugly, unless you special case the breakpoint printouts so 
that it says the one "visible" breakpoint is at pc x, y, z, rather than 
just x (the code to do this is probably ugly too in this method).

Another way is to do this is make it all invisible to the user, but 
still have "hidden" breakpoints is to make breakpoints have an 
associate set of methods, where they perform this magic internally.

You could also just make a hierarchy of breakpoints and avoid the magic 
methods and hiding altogether.
You have one parent breakpoint named "Foo:Foo" that just consists of 3 
sub-breakpoints, each at the right place in the constructor.

Only non-hidden top level breakpoints (since i imagine in some 
extremely complex case, one could want to have a subbreakpoint 
consisting of subbreakpoints) are visible, and thus, Foo:Foo is visible 
in an info breakpoints printout, but it's sub-breakpoints aren't (You 
can either just make it print "exists at multiple pc's, or recursively 
print out the pc's of the sub breakpoints).

Hitting one of the subbreakpoints doesn't require any magic, since what 
we say is that we've hit the parent breakpoint, "Foo:Foo".

--Dan

  reply	other threads:[~2003-04-30  5:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-30  4:36 Michael Elizabeth Chastain
2003-04-30  5:20 ` Daniel Berlin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-12-15 14:06 Breakpoints " Amit Kale
2005-12-26  7:52 ` Amit Kale
2005-12-27  4:07   ` Jim Blandy
2003-04-30 14:44 breakpoints " Michael Elizabeth Chastain
2003-05-01  2:13 ` Daniel Berlin
2003-04-18 20:04 David Carlton
2003-04-24 14:50 ` Daniel Jacobowitz
2003-04-24 22:02   ` Paul Koning
2003-04-25  0:30     ` Daniel Jacobowitz
2003-04-29 20:45   ` Paul Koning
2003-04-29 21:24     ` Daniel Jacobowitz
2003-04-30 19:04       ` Michael Eager
2003-04-30 19:11         ` Paul Koning
2003-04-30 19:19         ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=662F2E4E-7ACB-11D7-8FE3-000A95A34564@dberlin.org \
    --to=dberlin@dberlin.org \
    --cc=carlton@bactrian.org \
    --cc=drow@mvista.com \
    --cc=gdb@sources.redhat.com \
    --cc=mec@shout.net \
    --cc=pkoning@equallogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).