* 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).