From: Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de>
To: gdb@sources.redhat.com
Subject: C++ pointer-to-member handling broken?
Date: Wed, 21 Apr 2004 18:44:00 -0000 [thread overview]
Message-ID: <200404211843.UAA26279@faui1d.informatik.uni-erlangen.de> (raw)
Hello,
it looks like the handling of C++ pointers to members is broken at the moment;
the assumptions GDB makes about how these data structures are layed out by
the compiler do not match what any (recent) GCC does ...
Two issues that are currently causing testcase failures on s390x:
- For pointer to data members, GDB assumes (in cp_print_class_member
(cp-valprint.c)) that these are of type 'int' and hold the byte
offset.
This is incorrect on s390x (and other 64-bit platforms): they
should by of type 'ptrdiff_t' (which is 'long') according to
the GCC 3.x C++ ABI.
Note that GDB is even incompatible with itself here: in
value_struct_elt_for_reference (valops.c), when it generates
a pointer-to-data-member value, they are stored as *addresses*
(e.g. 64-bit).
This causes a test case failure on s390x-ibm-linux:
FAIL: gdb.cp/classes.exp: print Bar::z
- For pointer to member functions, GDB needs to be aware of how
the compiler distinguishes between virtual and non-virtual
member functions. This is currently done using these macros
in value.h:
/* Pointer to member function. Depends on compiler implementation. */
#define METHOD_PTR_IS_VIRTUAL(ADDR) ((ADDR) & 0x80000000)
#define METHOD_PTR_FROM_VOFFSET(OFFSET) (0x80000000 + (OFFSET))
#define METHOD_PTR_TO_VOFFSET(ADDR) (~0x80000000 & (ADDR))
This does not adhere to the GCC 3.x ABI on any platform, which
uses a pair of (address or vtable offset) and this-adjust delta,
where virtual functions are marked either by the *low* bit of
the address, or by the low bit of the delta, depending on whether
the platform supports functions starting at odd addresses or not.
On s390(x), the low bit of the address is used, while this test
checks the high bit. Thus, virtual functions are not detected
correctly.
Even worse, on s390x the default starting address of executables
is 0x80000000. This means that *normal* functions are frequently
misdetected as virtual; this causes the test case failure:
FAIL: gdb.cp/printmethod.exp: print virtual method.
Any suggestions how to fix this? I guess there should be some target
interface that allows the target to define the format of pointers to
members according to the platform's ABI ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de
reply other threads:[~2004-04-21 18:43 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=200404211843.UAA26279@faui1d.informatik.uni-erlangen.de \
--to=weigand@i1.informatik.uni-erlangen.de \
--cc=gdb@sources.redhat.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).