From: Daniel Berlin <dan@cgsoftware.com>
To: Jim Blandy <jimb@zwingli.cygnus.com>
Cc: gdb-patches@sources.redhat.com, gdb@sources.redhat.com
Subject: Re: RFA: add support for GNU V3 C++ ABI
Date: Mon, 21 May 2001 18:19:00 -0000 [thread overview]
Message-ID: <87pud218po.fsf@dynamic-addr-83-177.resnet.rochester.edu> (raw)
In-Reply-To: <20010521174112.6202F5E9CB@zwingli.cygnus.com>
Jim Blandy <jimb@zwingli.cygnus.com> writes:
> This is a first cut at supporting the new V3 C++ ABI. It provides all
> the functions currently abstracted in the cp-abi.h interface,
> including RTTI and virtual function calls.
>
> It doesn't handle virtual base classes, since there is no support for
> that in cp-abi.h; hopefully, that'll be addressed soon.
>
The patch is approved (the part i can approve, anyway. The minsym
stuff isn't mine to approve, but I can at least vouch for it's
correctness. There is no case where a v3 mangled symbol doesn't start
with "_Z". We default to the v2 abi, so we don't need to check for
that ABI and switch.)
And if someone from HP doesn't get back to me in about 1 week, tops, i'm
just going to say "screw it", and if the baseclass_offset stuff breaks
the HP aCC stuff, then when someone knowledgable enough to fix it
comes along, they'll fix it.
This is actually what is holding me up. I'm trying hard to do the
right thing here, and make sure we didn't break it, but without access
to an HP machine with HP aCC and a lot of time to reverse engineer all
the cases, and without anyone who will answer the C++ ABI related
questions, I can't maintain or support it.
I'd normally be happy to let it sit there bit rot, but we can't in
this case (because moving baseclass_offset to a common area requires
changing it's args to be a superset of find_rt_vbase_offset and
baseclass_offset, and find_rt_vbase_offset wants an argument that we
can't always give it), and since it's holding up support for an ABI for a
new version of the GNU compiler, which is, IMHO, more important than
code nobody seems willing to even answer questions about the
algorithms it's using, ...
It's also likely it's not incorrect, we just can't prove it without
knowing how to do it ourselves.
If anyone else on the list knows how to calculate baseclass offset
addresses for the HP aCC ABI, and thus, could tell me if a small piece
of code is correct, or explain the algorithm in english, i'd greatly appreciate it.
--Dan
next prev parent reply other threads:[~2001-05-21 18:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-21 10:40 Jim Blandy
2001-05-21 18:19 ` Daniel Berlin [this message]
2001-05-21 18:51 ` Stan Shebs
2001-05-22 13:54 ` Jim Blandy
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=87pud218po.fsf@dynamic-addr-83-177.resnet.rochester.edu \
--to=dan@cgsoftware.com \
--cc=gdb-patches@sources.redhat.com \
--cc=gdb@sources.redhat.com \
--cc=jimb@zwingli.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