* Problem with virtual function pointers
@ 2003-03-27 14:24 Corinna Vinschen
2003-03-27 14:53 ` Daniel Jacobowitz
0 siblings, 1 reply; 6+ messages in thread
From: Corinna Vinschen @ 2003-03-27 14:24 UTC (permalink / raw)
To: gdb
Hi,
I'm just investigating a problem which XStormy16 gets in
gdb.c++/printmethod.exp:
print theA->virt^M
$1 = invalid pointer to member function^M
FAIL: gdb.c++/printmethod.exp: print virtual method.
It turned out that the error happens in xstormy16_pointer_to_address().
This function converts an address to a jump table entry into a pointer
to the actual function. To do this, it calls a conversion routine,
which is only called if the following condition applies:
enum type_code target = TYPE_CODE (TYPE_TARGET_TYPE (type));
if (target == TYPE_CODE_FUNC || target == TYPE_CODE_METHOD)
convert();
Surprisingly (at least for me) this fails for the above case. Looking
into type, I found that type is TYPE_CODE_PTR which is correct, but
target_type is TYPE_CODE_VOID! Sure, the above virtual method is of
type void but is that really ok? Shouldn't that be
type: TYPE_CODE_PTR
type->target_type: TYPE_CODE_METHOD
type->target_type->target_type: TYPE_CODE_VOID
?
Does somebody know why that happens? Is that just a bug in gdb? Or
could that be related to incorrect debug info from gcc?
Corinna
--
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problem with virtual function pointers
2003-03-27 14:24 Problem with virtual function pointers Corinna Vinschen
@ 2003-03-27 14:53 ` Daniel Jacobowitz
2003-03-27 15:20 ` Corinna Vinschen
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Jacobowitz @ 2003-03-27 14:53 UTC (permalink / raw)
To: gdb
On Thu, Mar 27, 2003 at 03:24:12PM +0100, Corinna Vinschen wrote:
> Hi,
>
> I'm just investigating a problem which XStormy16 gets in
> gdb.c++/printmethod.exp:
>
> print theA->virt^M
> $1 = invalid pointer to member function^M
> FAIL: gdb.c++/printmethod.exp: print virtual method.
>
> It turned out that the error happens in xstormy16_pointer_to_address().
> This function converts an address to a jump table entry into a pointer
> to the actual function. To do this, it calls a conversion routine,
> which is only called if the following condition applies:
>
>
> enum type_code target = TYPE_CODE (TYPE_TARGET_TYPE (type));
>
> if (target == TYPE_CODE_FUNC || target == TYPE_CODE_METHOD)
> convert();
>
> Surprisingly (at least for me) this fails for the above case. Looking
> into type, I found that type is TYPE_CODE_PTR which is correct, but
> target_type is TYPE_CODE_VOID! Sure, the above virtual method is of
> type void but is that really ok? Shouldn't that be
>
> type: TYPE_CODE_PTR
> type->target_type: TYPE_CODE_METHOD
> type->target_type->target_type: TYPE_CODE_VOID
>
> ?
Could you give me a backtrace?
> Does somebody know why that happens? Is that just a bug in gdb? Or
> could that be related to incorrect debug info from gcc?
I believe this has to do with the type info emitted for virtual
function tables, but I need to see the backtrace to confirm. If so I'm
not sure whether it's really a bug in GCC or GDB...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problem with virtual function pointers
2003-03-27 14:53 ` Daniel Jacobowitz
@ 2003-03-27 15:20 ` Corinna Vinschen
2003-03-27 15:26 ` Daniel Jacobowitz
0 siblings, 1 reply; 6+ messages in thread
From: Corinna Vinschen @ 2003-03-27 15:20 UTC (permalink / raw)
To: gdb
On Thu, Mar 27, 2003 at 09:53:46AM -0500, Daniel Jacobowitz wrote:
> On Thu, Mar 27, 2003 at 03:24:12PM +0100, Corinna Vinschen wrote:
> > Hi,
> >
> > I'm just investigating a problem which XStormy16 gets in
> > gdb.c++/printmethod.exp:
> >
> > print theA->virt^M
> > $1 = invalid pointer to member function^M
> > FAIL: gdb.c++/printmethod.exp: print virtual method.
> >
> > It turned out that the error happens in xstormy16_pointer_to_address().
> > This function converts an address to a jump table entry into a pointer
> > to the actual function. To do this, it calls a conversion routine,
> > which is only called if the following condition applies:
> >
> >
> > enum type_code target = TYPE_CODE (TYPE_TARGET_TYPE (type));
> >
> > if (target == TYPE_CODE_FUNC || target == TYPE_CODE_METHOD)
> > convert();
> >
> > Surprisingly (at least for me) this fails for the above case. Looking
> > into type, I found that type is TYPE_CODE_PTR which is correct, but
> > target_type is TYPE_CODE_VOID! Sure, the above virtual method is of
> > type void but is that really ok? Shouldn't that be
> >
> > type: TYPE_CODE_PTR
> > type->target_type: TYPE_CODE_METHOD
> > type->target_type->target_type: TYPE_CODE_VOID
> >
> > ?
>
> Could you give me a backtrace?
Sure. The situation is after calling `print theA->virt' and stepping
into xstormy16_pointer_to_address().
(top-gdb) bt
#0 xstormy16_pointer_to_address (type=0x848d628, buf=0x85f4348)
at /home/corinna/src/gdb/xstormy16-tdep.c:966
#1 0x080fa69e in gdbarch_pointer_to_address (gdbarch=0x848ac90,
type=0x848d628, buf=0x85f4348)
at /home/corinna/src/gdb/gdbarch.c:4164
#2 0x080b3219 in extract_typed_address (buf=0x85f4348, type=0x848d628)
at /home/corinna/src/gdb/findvar.c:197
#3 0x080bc1a3 in unpack_long (type=0x848d628, valaddr=0x85f4348 ":®")
at /home/corinna/src/gdb/values.c:696
#4 0x080bc2a6 in unpack_pointer (type=0x848d628, valaddr=0x85f4348 ":®")
at /home/corinna/src/gdb/values.c:775
#5 0x0813876e in cp_print_class_method (valaddr=0x85f4348 ":®",
type=0x84aa064, stream=0x8490f08)
at /home/corinna/src/gdb/cp-valprint.c:90
#6 0x08138184 in c_val_print (type=0x84a9814, valaddr=0x85f4160 "hA_\b\t ",
embedded_offset=0, address=162698, stream=0x8490f08, format=0,
deref_ref=1, recurse=0, pretty=Val_no_prettyprint)
at /home/corinna/src/gdb/c-valprint.c:447
#7 0x080cc330 in val_print (type=0x84a9814, valaddr=0x85f4160 "hA_\b\t ",
embedded_offset=0, address=162698, stream=0x8490f08, format=0,
deref_ref=1, recurse=0, pretty=Val_no_prettyprint)
at /home/corinna/src/gdb/valprint.c:152
#8 0x081386eb in c_value_print (val=0x85f4128, stream=0x8490f08, format=0,
pretty=Val_pretty_default)
at /home/corinna/src/gdb/c-valprint.c:596
#9 0x080cc39d in value_print (val=0x85f4128, stream=0x8490f08, format=0,
pretty=Val_pretty_default)
at /home/corinna/src/gdb/valprint.c:175
#10 0x080ce28f in print_formatted (val=0x85f4128, format=0, size=0,
stream=0x8490f08)
at /home/corinna/src/gdb/printcmd.c:328
#11 0x080cf2cf in print_command_1 (exp=0x846fd0a "theA->virt", inspect=0,
voidprint=1) at /home/corinna/src/gdb/printcmd.c:931
#12 0x080cf33d in print_command (exp=0x846fd0a "theA->virt", from_tty=1)
at /home/corinna/src/gdb/printcmd.c:952
[etc]
Corinna
--
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problem with virtual function pointers
2003-03-27 15:20 ` Corinna Vinschen
@ 2003-03-27 15:26 ` Daniel Jacobowitz
2003-03-27 16:18 ` Corinna Vinschen
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Jacobowitz @ 2003-03-27 15:26 UTC (permalink / raw)
To: gdb
On Thu, Mar 27, 2003 at 04:20:22PM +0100, Corinna Vinschen wrote:
> On Thu, Mar 27, 2003 at 09:53:46AM -0500, Daniel Jacobowitz wrote:
> > On Thu, Mar 27, 2003 at 03:24:12PM +0100, Corinna Vinschen wrote:
> > > Hi,
> > >
> > > I'm just investigating a problem which XStormy16 gets in
> > > gdb.c++/printmethod.exp:
> > >
> > > print theA->virt^M
> > > $1 = invalid pointer to member function^M
> > > FAIL: gdb.c++/printmethod.exp: print virtual method.
> > >
> > > It turned out that the error happens in xstormy16_pointer_to_address().
> > > This function converts an address to a jump table entry into a pointer
> > > to the actual function. To do this, it calls a conversion routine,
> > > which is only called if the following condition applies:
> > >
> > >
> > > enum type_code target = TYPE_CODE (TYPE_TARGET_TYPE (type));
> > >
> > > if (target == TYPE_CODE_FUNC || target == TYPE_CODE_METHOD)
> > > convert();
> > >
> > > Surprisingly (at least for me) this fails for the above case. Looking
> > > into type, I found that type is TYPE_CODE_PTR which is correct, but
> > > target_type is TYPE_CODE_VOID! Sure, the above virtual method is of
> > > type void but is that really ok? Shouldn't that be
> > >
> > > type: TYPE_CODE_PTR
> > > type->target_type: TYPE_CODE_METHOD
> > > type->target_type->target_type: TYPE_CODE_VOID
> > >
> > > ?
> >
> > Could you give me a backtrace?
>
> Sure. The situation is after calling `print theA->virt' and stepping
> into xstormy16_pointer_to_address().
>
> (top-gdb) bt
> #0 xstormy16_pointer_to_address (type=0x848d628, buf=0x85f4348)
> at /home/corinna/src/gdb/xstormy16-tdep.c:966
> #1 0x080fa69e in gdbarch_pointer_to_address (gdbarch=0x848ac90,
> type=0x848d628, buf=0x85f4348)
> at /home/corinna/src/gdb/gdbarch.c:4164
> #2 0x080b3219 in extract_typed_address (buf=0x85f4348, type=0x848d628)
> at /home/corinna/src/gdb/findvar.c:197
> #3 0x080bc1a3 in unpack_long (type=0x848d628, valaddr=0x85f4348 ":®")
> at /home/corinna/src/gdb/values.c:696
> #4 0x080bc2a6 in unpack_pointer (type=0x848d628, valaddr=0x85f4348 ":®")
> at /home/corinna/src/gdb/values.c:775
> #5 0x0813876e in cp_print_class_method (valaddr=0x85f4348 ":®",
> type=0x84aa064, stream=0x8490f08)
> at /home/corinna/src/gdb/cp-valprint.c:90
There's your bug, right on schedule. Look at the line:
addr = unpack_pointer (lookup_pointer_type (builtin_type_void), valaddr);
Recommend using builtin_type_void_func_ptr instead of
lookup_pointer_type (builtin_type_void). Does that fix it?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problem with virtual function pointers
2003-03-27 15:26 ` Daniel Jacobowitz
@ 2003-03-27 16:18 ` Corinna Vinschen
2003-04-01 17:34 ` Corinna Vinschen
0 siblings, 1 reply; 6+ messages in thread
From: Corinna Vinschen @ 2003-03-27 16:18 UTC (permalink / raw)
To: gdb
On Thu, Mar 27, 2003 at 10:26:52AM -0500, Daniel Jacobowitz wrote:
> There's your bug, right on schedule. Look at the line:
> addr = unpack_pointer (lookup_pointer_type (builtin_type_void), valaddr);
>
> Recommend using builtin_type_void_func_ptr instead of
> lookup_pointer_type (builtin_type_void). Does that fix it?
Yes, it does fix the problem. Thank you!
However, I don't understand why it's done this way. The incoming
type into this function is already correct AFAICS (well, this time,
I didn't get it when I wrote my first posting, apparently). type
is a TYPE_CODE_PTR to a TYPE_CODE_METHOD to TYPE_CODE_VOID.
So, from my point of view the correct call would just be
addr = unpack_pointer (type, valaddr);
Why isn't type just used as is?
Btw., I've just ran the full c++ testsuite again and using just type shows
no regressions (for xstormy16).
Corinna
--
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problem with virtual function pointers
2003-03-27 16:18 ` Corinna Vinschen
@ 2003-04-01 17:34 ` Corinna Vinschen
0 siblings, 0 replies; 6+ messages in thread
From: Corinna Vinschen @ 2003-04-01 17:34 UTC (permalink / raw)
To: gdb
Is there any news on that?
Corinna
On Thu, Mar 27, 2003 at 05:18:24PM +0100, Corinna Vinschen wrote:
> On Thu, Mar 27, 2003 at 10:26:52AM -0500, Daniel Jacobowitz wrote:
> > There's your bug, right on schedule. Look at the line:
> > addr = unpack_pointer (lookup_pointer_type (builtin_type_void), valaddr);
> >
> > Recommend using builtin_type_void_func_ptr instead of
> > lookup_pointer_type (builtin_type_void). Does that fix it?
>
> Yes, it does fix the problem. Thank you!
>
> However, I don't understand why it's done this way. The incoming
> type into this function is already correct AFAICS (well, this time,
> I didn't get it when I wrote my first posting, apparently). type
> is a TYPE_CODE_PTR to a TYPE_CODE_METHOD to TYPE_CODE_VOID.
>
> So, from my point of view the correct call would just be
>
> addr = unpack_pointer (type, valaddr);
>
> Why isn't type just used as is?
>
> Btw., I've just ran the full c++ testsuite again and using just type shows
> no regressions (for xstormy16).
>
>
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Developer
> Red Hat, Inc.
> mailto:vinschen@redhat.com
--
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-04-01 17:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-27 14:24 Problem with virtual function pointers Corinna Vinschen
2003-03-27 14:53 ` Daniel Jacobowitz
2003-03-27 15:20 ` Corinna Vinschen
2003-03-27 15:26 ` Daniel Jacobowitz
2003-03-27 16:18 ` Corinna Vinschen
2003-04-01 17:34 ` Corinna Vinschen
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).