From: Daniel Berlin <dan@www.cgsoftware.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Alexandre Oliva <aoliva@redhat.com>,
Jim Wilson <wilson@cygnus.com>, <gcc@gcc.gnu.org>,
<gcc-patches@gcc.gnu.org>, <gdb@sources.redhat.com>
Subject: Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT
Date: Tue, 17 Apr 2001 13:02:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.33.0104171544230.9127-100000@www.cgsoftware.com> (raw)
In-Reply-To: <3ADC6574.FA61742A@cygnus.com>
On Tue, 17 Apr 2001, Andrew Cagney wrote:
> Alexandre Oliva wrote:
> >
> > On Apr 6, 2001, Jim Wilson <wilson@cygnus.com> wrote:
> >
> > >In article <ork84ys5bq.fsf@guarana.lsd.ic.unicamp.br> you write:
> >
> > >> The C++ ABI v3 uses the least significant bit of the pfn to tell
> > >> non-virtual from virtual functions.
>
> > > There are also targets that use the low-order bit of the PC to determine
> > > processor mode.
> >
> > Good point. I think this is enough of a reason for us to have a
> > target configuration flag to switch between two different
> > representations of pointers to member functions. I wonder how GDB is
> > going to be able to tell one representation from the other... Perhaps
> > it's going to have to be hard-coded in GDB?
>
> Remember, nothing in GDB is hard coded (only half :-^).
>
And when it comes to C++ stuf, i refuse to hard code any more stuff, after
just spending months cleaning up the crud from 5 years of doing that.
> Either the v3 ABI would need to specify the exact mechanism that is
> valid for ISA foo (i.e. GDB would would be wired to assume that all MIPS
> use mechanism XYZ) or the debug/object info would need to describe the
> mechanism being used so that GDB could adjust its self accordingly.
It's easiest to do this in debug info.
At least, for dwarf (I dunno how tod ot he same in stabs).
In the type die of the ptr-to-member die, just add a GCC specific
attribute that says which bit to check for virtuality, and i'll modify
gdb to handle it right (by telling the C++ ABI abstraction layer which
bit to
check)
> > Andrew >
next prev parent reply other threads:[~2001-04-17 13:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200104062005.NAA13684@wilson.cygnus.com>
2001-04-09 8:19 ` Alexandre Oliva
2001-04-09 12:29 ` Joern Rennecke
2001-04-09 13:12 ` Alexandre Oliva
2001-04-09 13:42 ` Joern Rennecke
2001-04-18 5:48 ` Richard Earnshaw
2001-04-18 12:11 ` Alexandre Oliva
2001-04-10 9:27 ` C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 *BITS_PER_UNIT Mark Mitchell
2001-04-17 10:38 ` C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT Andrew Cagney
2001-04-17 13:02 ` Daniel Berlin [this message]
2001-05-16 4:53 ` Jason Merrill
2001-05-16 7:18 ` Daniel Berlin
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=Pine.LNX.4.33.0104171544230.9127-100000@www.cgsoftware.com \
--to=dan@www.cgsoftware.com \
--cc=ac131313@cygnus.com \
--cc=aoliva@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gcc@gcc.gnu.org \
--cc=gdb@sources.redhat.com \
--cc=wilson@cygnus.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