|
Robert D'Attilio(deleted)
|
GDB (on PPC target) can't step into functions derived from abstract class
|
|
Robert D'Attilio(deleted)
02/19/2009 11:15 AM
post22536
|
GDB (on PPC target) can't step into functions derived from abstract class
Hi:
I'm experiencing a problem with gdb when trying to step into functions of a class that are derived from an abstract base
class. I've been able to reproduce the problem on a simple example which I've included below:
#include <stdio.h>
class Base
{
public:
virtual void hello();
virtual void run()=0;
};
class Derived : public Base
{
public:
void run();
};
void Base::hello(){printf("Base::Hello()\n");}
void Derived::run(){printf("Dervied::Run\n");}
int main (int argc, char *argv[])
{
Base* pBase = new Derived();
pBase->hello();
pBase->run();
return 0;
}
If I try to step into the calls to pBase->hello() or pBase->run(), the debugger ends up in some QNX library code
(MsgSendv() 0xfe339f64) but never reaches my implementation (the printf calls). However, I can set breakpoints within
the hello() or run() methods and the debugger will stop on them.
Here are the relevant build and target details:
QNX 6.3.2
qcc: 3.3.5 - building with -g and no optimization
gdb: 6.7 (5.2.1)
target: PPC405EP
host: linux
IDE: 4.5 - Note: I normally debug from the IDE but I was able to reproduce the behaviour by just running gdb directly.
I dug a little further looking at the assembly and single-stepping through that and the problem seems to be related to
the bctrl branch instruction which the debugger can't seem to be able to follow. Both function calls use the bctrl for
their branching. Here is the corresponding assembly for the call to hello()
48040714: 81 3f 00 10 lwz r9,16(r31)
48040718: 81 29 00 00 lwz r9,0(r9)
4804071c: 81 29 00 00 lwz r9,0(r9)
48040720: 7d 29 03 a6 mtctr r9
48040724: 80 7f 00 10 lwz r3,16(r31)
48040728: 4e 80 04 21 bctrl
Examination of the ctr register shows that it has the correct address for the start of the hello() method. Now if I make
all the methods non-virtual and adjust the instantiation accordingly, all the branches change from bctrl to bl and the
debugger is now able to step into the functions. I suspect the mtctr/bctrl constructs have to do with managing the
vtables?
Anyone else seen this behaviour or have an explanation or solution for why gdb can't follow the trail?
Thanks
Robert
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
Aleksandar Ristovski(deleted)
02/19/2009 11:56 AM
post22540
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
Robert D'Attilio wrote:
> Hi:
>
> I'm experiencing a problem with gdb when trying to step into functions of a class that are derived from an abstract
base class. I've been able to reproduce the problem on a simple example which I've included below:
>
> #include <stdio.h>
>
> class Base
> {
> public:
> virtual void hello();
> virtual void run()=0;
> };
>
> class Derived : public Base
> {
> public:
> void run();
> };
>
> void Base::hello(){printf("Base::Hello()\n");}
> void Derived::run(){printf("Dervied::Run\n");}
>
> int main (int argc, char *argv[])
> {
> Base* pBase = new Derived();
> pBase->hello();
> pBase->run();
>
> return 0;
> }
>
>
> If I try to step into the calls to pBase->hello() or pBase->run(), the debugger ends up in some QNX library code
(MsgSendv() 0xfe339f64) but never reaches my implementation (the printf calls). However, I can set breakpoints within
the hello() or run() methods and the debugger will stop on them.
>
> Here are the relevant build and target details:
> QNX 6.3.2
> qcc: 3.3.5 - building with -g and no optimization
> gdb: 6.7 (5.2.1)
^^^^^^^^^^^^^^^^^^^^^
Does this mean you tried with both gdb-6.7 and gdb-5.2.1?
Thanks,
Aleksandar
|
|
|
|
|
|
Robert D'Attilio(deleted)
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
Robert D'Attilio(deleted)
02/19/2009 12:11 PM
post22543
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Yes that is correct: I tried this on both gdb 6.7 and 5.2.1. Sorry for
the confusion.
Robert
-----Original Message-----
From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
Sent: Thursday, February 19, 2009 11:56 AM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
Robert D'Attilio wrote:
> Hi:
>
> I'm experiencing a problem with gdb when trying to step into functions
of a class that are derived from an abstract base class. I've been able
to reproduce the problem on a simple example which I've included below:
>
> #include <stdio.h>
>
> class Base
> {
> public:
> virtual void hello();
> virtual void run()=0;
> };
>
> class Derived : public Base
> {
> public:
> void run();
> };
>
> void Base::hello(){printf("Base::Hello()\n");}
> void Derived::run(){printf("Dervied::Run\n");}
>
> int main (int argc, char *argv[])
> {
> Base* pBase = new Derived();
> pBase->hello();
> pBase->run();
>
> return 0;
> }
>
>
> If I try to step into the calls to pBase->hello() or pBase->run(), the
debugger ends up in some QNX library code (MsgSendv() 0xfe339f64) but
never reaches my implementation (the printf calls). However, I can set
breakpoints within the hello() or run() methods and the debugger will
stop on them.
>
> Here are the relevant build and target details:
> QNX 6.3.2
> qcc: 3.3.5 - building with -g and no optimization
> gdb: 6.7 (5.2.1)
^^^^^^^^^^^^^^^^^^^^^
Does this mean you tried with both gdb-6.7 and gdb-5.2.1?
Thanks,
Aleksandar
_______________________________________________
General
http://community.qnx.com/sf/go/post22540
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
Aleksandar Ristovski(deleted)
02/19/2009 12:37 PM
post22546
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
I just tried and it worked for me.
Could you do a
(gdb) show version
in your 6.7 gdb and post it here?
Also, could you do the following on your binary (and post
the output):
# ntoppc-readelf -wi <your binary> | grep DW_AT_producer
Thanks,
Aleksandar
|
|
|
|
|
|
Robert D'Attilio(deleted)
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
Robert D'Attilio(deleted)
02/19/2009 1:15 PM
post22549
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Aleksandar:
Here is the info:
show version
GNU gdb 6.7 qnx-nto update 10 (rev. 254)
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=powerpc-unknown-nto-qnx6.3.0".
robert@WrBuildServer3: o-be $ ntoppc-readelf -wi TestPro | grep
W_AT_producer
DW_AT_producer : GNU C++ 3.3.5 (qnx-nto)
I'm curious to see the disassembly of what you compiled to see how it
compares with mine. Are your function calls invoked via bctrl machine
instruction?
-----Original Message-----
From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
Sent: Thursday, February 19, 2009 12:38 PM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
I just tried and it worked for me.
Could you do a
(gdb) show version
in your 6.7 gdb and post it here?
Also, could you do the following on your binary (and post
the output):
# ntoppc-readelf -wi <your binary> | grep DW_AT_producer
Thanks,
Aleksandar
_______________________________________________
General
http://community.qnx.com/sf/go/post22546
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
Aleksandar Ristovski(deleted)
02/19/2009 1:45 PM
post22552
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
Robert D'Attilio wrote:
>
> I'm curious to see the disassembly of what you compiled to see how it
> compares with mine. Are your function calls invoked via bctrl machine
> instruction?
>
It looks like it is. I attached the binary to this reply.
================= disassembly =====================
480407dc <main>:
480407dc: 94 21 ff d0 stwu r1,-48(r1)
480407e0: 7c 08 02 a6 mflr r0
480407e4: 93 a1 00 24 stw r29,36(r1)
480407e8: 93 e1 00 2c stw r31,44(r1)
480407ec: 90 01 00 34 stw r0,52(r1)
480407f0: 7c 3f 0b 78 mr r31,r1
480407f4: 90 7f 00 08 stw r3,8(r31)
480407f8: 90 9f 00 0c stw r4,12(r31)
480407fc: 38 60 00 04 li r3,4
48040800: 48 00 14 69 bl 48041c68 <_Znwj@plt>
48040804: 7c 7d 1b 78 mr r29,r3
48040808: 7f a3 eb 78 mr r3,r29
4804080c: 48 00 00 fd bl 48040908
<_ZN7DerivedC1Ev>
48040810: 7f a0 eb 78 mr r0,r29
48040814: 90 1f 00 10 stw r0,16(r31)
48040818: 81 3f 00 10 lwz r9,16(r31)
4804081c: 81 29 00 00 lwz r9,0(r9)
48040820: 81 29 00 00 lwz r9,0(r9)
48040824: 7d 29 03 a6 mtctr r9
48040828: 80 7f 00 10 lwz r3,16(r31)
4804082c: 4e 80 04 21 bctrl
48040830: 81 3f 00 10 lwz r9,16(r31)
48040834: 81 29 00 00 lwz r9,0(r9)
48040838: 39 29 00 04 addi r9,r9,4
4804083c: 81 29 00 00 lwz r9,0(r9)
48040840: 7d 29 03 a6 mtctr r9
48040844: 80 7f 00 10 lwz r3,16(r31)
48040848: 4e 80 04 21 bctrl
4804084c: 38 00 00 00 li r0,0
48040850: 7c 03 03 78 mr r3,r0
48040854: 81 61 00 00 lwz r11,0(r1)
48040858: 80 0b 00 04 lwz r0,4(r11)
4804085c: 7c 08 03 a6 mtlr r0
48040860: 83 ab ff f4 lwz r29,-12(r11)
48040864: 83 eb ff fc lwz r31,-4(r11)
48040868: 7d 61 5b 78 mr r1,r11
4804086c: 4e 80 00 20 blr
============== gdb session: ==============================
$ gdbu10/host/linux/x86/usr/bin/ntoppc-gdb $EXE --ex "target
qnx 10.42.122.79:8000" --ex "upload $EXE /tmp/derived"
GNU gdb 6.7 qnx-nto update 10 (rev. 254)
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and
redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type
"show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=powerpc-unknown-nto-qnx6.3.0"...
Remote debugging using 10.42.122.79:8000
MsgNak received - resending
Remote target is big-endian
(gdb) start
Temporary breakpoint 1 at 0x480407fc: file
/home/src/testcases/derivedcpp/derived.cpp, line 21.
Starting program: /mnt/win/derivedcppppcbe632-3.3.5
Remote: /tmp/derived
advancSetting Dynamic-Linker Breakpoint based on
/opt/qnx/target/qnx6//ppcbe/usr/lib/ldqnx.so.2
e warning: Host file
/opt/qnx640/target/qnx6/ppcbe/lib/libc.so.3 does not match
target file.
22
Temporary breakpoint 1, main (argc=1, argv=0x4803ff14)
at /home/src/testcases/derivedcpp/derived.cpp:21
21 Base* pBase = new Derived();
(gdb) advance 22
main (argc=1, argv=0x4803ff14) at
/home/src/testcases/derivedcpp/derived.cpp:22
22 pBase->hello();
(gdb) step
Base::hello (this=0x4804a2d8) at
/home/src/testcases/derivedcpp/derived.cpp:16
16 void Base::hello(){printf("Base::Hello()\n");}
(gdb) n
Base::Hello()
main (argc=1, argv=0x4803ff14) at
/home/src/testcases/derivedcpp/derived.cpp:23
23 pBase->run();
(gdb) show version
GNU gdb 6.7 qnx-nto update 10 (rev. 254)
Copyright (C) 2007 Free Software...
View Full Message
|
|
|
|
|
|
Robert D'Attilio(deleted)
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
Robert D'Attilio(deleted)
02/19/2009 3:43 PM
post22556
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
I tried launching your binary on my system (although I had to explicitly
download a different libcpp.so as we use the "Dinkum Abridged without
Exceptions" version - as an aside, I thought this (the different libcpp)
might be the problem but it wasn't). I stepped through the disassembly
and end up with the same behaviour as with my binary. Here is a stack
trace (of your binary) immediately after I try to step into hello().
#0 0xfe339f64 in MsgSendv () from
/opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
#1 0xfe35f14c in _devctl () from
/opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
#2 0xfe318f18 in isatty () from
/opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
#3 0xfe34dd50 in _Fbuf () from
/opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
#4 0xfe34e48c in _Fwprep () from
/opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
#5 0xfe34c0ec in fwrite () from
/opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
#6 0xfe34dfb8 in _Fprout () from
/opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
#7 0xfe351478 in _Printf () from
/opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
#8 0xfe34c690 in printf () from
/opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
#9 0x48040784 in Base::hello (this=0x48044330) at
/home/src/testcases/derivedcpp/derived.cpp:16
#10 0x48040830 in main (argc=1, argv=0x4803fe74) at
/home/src/testcases/derivedcpp/derived.cpp:22
It almost seems as if we're jumping directly into the printf() function
call from within hello(). On a hunch, I've tried inserting additional
'C' statements before the printf() statement in hello() but it doesn't
help.
I'm running out of ideas...can I see the output of your build command
(compile and link options) to compare it with mine?
robert
-----Original Message-----
From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
Sent: Thursday, February 19, 2009 1:46 PM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
Robert D'Attilio wrote:
>
> I'm curious to see the disassembly of what you compiled to see how it
> compares with mine. Are your function calls invoked via bctrl machine
> instruction?
>
It looks like it is. I attached the binary to this reply.
================= disassembly =====================
480407dc <main>:
480407dc: 94 21 ff d0 stwu r1,-48(r1)
480407e0: 7c 08 02 a6 mflr r0
480407e4: 93 a1 00 24 stw r29,36(r1)
480407e8: 93 e1 00 2c stw r31,44(r1)
480407ec: 90 01 00 34 stw r0,52(r1)
480407f0: 7c 3f 0b 78 mr r31,r1
480407f4: 90 7f 00 08 stw r3,8(r31)
480407f8: 90 9f 00 0c stw r4,12(r31)
480407fc: 38 60 00 04 li r3,4
48040800: 48 00 14 69 bl 48041c68 <_Znwj@plt>
48040804: 7c 7d 1b 78 mr r29,r3
48040808: 7f a3 eb 78 mr r3,r29
4804080c: 48 00 00 fd bl 48040908
<_ZN7DerivedC1Ev>
48040810: 7f a0 eb 78 mr r0,r29
48040814: 90 1f 00 10 stw r0,16(r31)
48040818: 81 3f 00 10 lwz r9,16(r31)
4804081c: 81 29 00 00 lwz r9,0(r9)
48040820: 81 29 00 00 lwz r9,0(r9)
48040824: 7d 29 03 a6 mtctr r9
48040828: 80 7f 00 10 lwz r3,16(r31)
4804082c: 4e 80 04 21 bctrl
48040830: 81 3f 00 10 lwz r9,16(r31)
48040834: 81 29 00 00 lwz r9,0(r9)
48040838: 39 29 00 04 addi r9,r9,4
4804083c: 81 29 00 00 lwz r9,0(r9)
48040840: 7d 29 03 a6 mtctr r9
48040844: 80 7f 00 10 lwz r3,16(r31)
48040848: 4e 80 04 21 bctrl
4804084c: 38 00 00 00 li r0,0
48040850: 7c 03 03 78 mr r3,r0
48040854: 81 61 00 00 lwz r11,0(r1)
48040858: 80 0b 00 04 lwz r0,4(r11)
4804085c: 7c 08 03 a6 mtlr r0
48040860: 83 ab ff f4 lwz ...
View Full Message
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
Aleksandar Ristovski(deleted)
02/19/2009 4:17 PM
post22561
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
Robert D'Attilio wrote:
> I tried launching your binary on my system (although I had to explicitly
> download a different libcpp.so as we use the "Dinkum Abridged without
> Exceptions" version - as an aside, I thought this (the different libcpp)
> might be the problem but it wasn't). I stepped through the disassembly
> and end up with the same behaviour as with my binary. Here is a stack
> trace (of your binary) immediately after I try to step into hello().
you stepped through disassembly with 'stepi', or just did
step again once you stopped in Base::hello (or run)? If you
could, post exact commands you issued to gdb before you got
to this point.
>
> #0 0xfe339f64 in MsgSendv () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #1 0xfe35f14c in _devctl () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #2 0xfe318f18 in isatty () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #3 0xfe34dd50 in _Fbuf () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #4 0xfe34e48c in _Fwprep () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #5 0xfe34c0ec in fwrite () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #6 0xfe34dfb8 in _Fprout () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #7 0xfe351478 in _Printf () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #8 0xfe34c690 in printf () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #9 0x48040784 in Base::hello (this=0x48044330) at
> /home/src/testcases/derivedcpp/derived.cpp:16
> #10 0x48040830 in main (argc=1, argv=0x4803fe74) at
> /home/src/testcases/derivedcpp/derived.cpp:22
>
> It almost seems as if we're jumping directly into the printf() function
> call from within hello(). On a hunch, I've tried inserting additional
> 'C' statements before the printf() statement in hello() but it doesn't
> help.
Do you see any warnings about mismatched libraries at the
beginning of debugging session (do a 'start' at the
beginning, it will run to main and stop there. There will be
message about libc.so.2 and warnings if any).
Be aware that I run the binary on a 6.4.0 system. It might
have something to do with it - I will have to try it on a
6.3.2 system (working on it).
>
> I'm running out of ideas...can I see the output of your build command
> (compile and link options) to compare it with mine?
>
$ QNX_TARGET=/opt/qnx632/target/qnx6/
QNX_HOST=/opt/qnx632/host/linux/x86/ make CCOPTS=-v
LDOPTS=-v GCC_VERSION=3.3.5
/opt/qnx632/host/linux/x86//usr/bin/qcc -V3.3.5,gcc_ntoppc
-c -Wc,-mno-fp-moves -Wc,-Wall -Wc,-Wno-parentheses
-I. -I/home/src/testcases/derivedcpp/nto/ppc/be
-I/home/src/testcases/derivedcpp/nto/ppc/o-be-g
-I/home/src/testcases/derivedcpp/nto/ppc
-I/home/src/testcases/derivedcpp/nto
-I/home/src/testcases/derivedcpp
-I/opt/qnx632/target/qnx6/usr/include -EB -g
-DVARIANT_be -DVARIANT_g -v
/home/src/testcases/derivedcpp/derived.cpp
cc: looking for gcc_ntoppcbe+debug in
/opt/qnx632/host/linux/x86//etc/qcc/gcc/3.3.5/gcc_ntoppcbe++.conf
cc: looking for gcc_ntoppcbe+debug in
/opt/qnx632/host/linux/x86//etc/qcc/gcc/3.3.5/gcc_ntoppcbe.conf
/opt/qnx632/host/linux/x86//usr/lib/gcc-lib/powerpc-unknown-nto-qnx6.3.0/3.3.5/cc1plus
-I. -I/home/src/testcases/derivedcpp/nto/ppc/be
-I/home/src/testcases/derivedcpp/nto/ppc/o-be-g
-I/home/src/testcases/derivedcpp/nto/ppc
-I/home/src/testcases/derivedcpp/nto
-I/home/src/testcases/derivedcpp
-I/opt/qnx632/target/qnx6/usr/include -g2 -DVARIANT_be
-DVARIANT_g -quiet -fno-builtin -mno-fp-moves -nostdinc
-nostdinc++ -D__cplusplus -D__QNX__ -D__QNXNTO__
-D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=5
-D__GNUG__=3 -D__GXX_ABI_VERSION=102 -D__NO_INLINE__
-D__DEPRECATED -D__EXCEPTIONS -D__unix__ -D__unix -D__ELF__
-D__PPC -D_ARCH_PPC -D_CALL_SYSV...
View Full Message
|
|
|
|
|
|
Robert D'Attilio(deleted)
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
Robert D'Attilio(deleted)
02/19/2009 4:48 PM
post22567
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Here is a trace of what I am doing. Note I am debugging from the IDE and
typically use the 'step over' and 'step into' buttons but to illustrate
what I am doing I have entered the following commands manaully on the
gdb console in the IDE:
When the excutable launches it stops at the line:
Base* pBase = new Derived();
I use the 'next' command to step over to the next source line
pBase->hello();
next
next
22 pBase->hello();
Then I use a series of 'stepi' commands to execute the machine
instructions to 'step into' the function hello().
stepi
stepi
0x4804081c 22 pBase->hello();
stepi
stepi
0x48040820 22 pBase->hello();
stepi
stepi
0x48040824 22 pBase->hello();
stepi
stepi
0x48040828 22 pBase->hello();
stepi
stepi
0x4804082c 22 pBase->hello();
stepi
stepi
0xfe339f64 in MsgSendv () from
/opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
Here is the disassembly for the above:
pBase->hello();
48040818: 81 3f 00 10 lwz r9,16(r31)
4804081c: 81 29 00 00 lwz r9,0(r9)
48040820: 81 29 00 00 lwz r9,0(r9)
48040824: 7d 29 03 a6 mtctr r9
48040828: 80 7f 00 10 lwz r3,16(r31)
4804082c: 4e 80 04 21 bctrl
One interesting point, if before doing the stepi instructions above, I
insert a breakpoint on the printf() statement in hello(), the stepi
instructions will successfully step into the hello() function and halt
on the printf() function call.
-----Original Message-----
From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
Sent: Thursday, February 19, 2009 4:18 PM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
Robert D'Attilio wrote:
> I tried launching your binary on my system (although I had to
explicitly
> download a different libcpp.so as we use the "Dinkum Abridged without
> Exceptions" version - as an aside, I thought this (the different
libcpp)
> might be the problem but it wasn't). I stepped through the disassembly
> and end up with the same behaviour as with my binary. Here is a stack
> trace (of your binary) immediately after I try to step into hello().
you stepped through disassembly with 'stepi', or just did
step again once you stopped in Base::hello (or run)? If you
could, post exact commands you issued to gdb before you got
to this point.
>
> #0 0xfe339f64 in MsgSendv () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #1 0xfe35f14c in _devctl () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #2 0xfe318f18 in isatty () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #3 0xfe34dd50 in _Fbuf () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #4 0xfe34e48c in _Fwprep () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #5 0xfe34c0ec in fwrite () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #6 0xfe34dfb8 in _Fprout () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #7 0xfe351478 in _Printf () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #8 0xfe34c690 in printf () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
> #9 0x48040784 in Base::hello (this=0x48044330) at
> /home/src/testcases/derivedcpp/derived.cpp:16
> #10 0x48040830 in main (argc=1, argv=0x4803fe74) at
> /home/src/testcases/derivedcpp/derived.cpp:22
>
> It almost seems as if we're jumping directly into the printf()
function
> call from within hello(). On a hunch, I've tried inserting additional
> 'C' statements before the printf() statement in hello() but it doesn't
> help.
Do you see any warnings about mismatched libraries at the
beginning of debugging session (do a 'start' at the
beginning, it will run to main and stop there. There will be
message about libc.so.2 and warnings if any).
Be aware that I run the binary on a 6.4.0 system. It might
have something to do...
View Full Message
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
Aleksandar Ristovski(deleted)
02/19/2009 5:15 PM
post22572
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
Robert D'Attilio wrote:
> Here is a trace of what I am doing. Note I am debugging from the IDE and
> typically use the 'step over' and 'step into' buttons but to illustrate
> what I am doing I have entered the following commands manaully on the
> gdb console in the IDE:
>
> When the excutable launches it stops at the line:
> Base* pBase = new Derived();
>
> I use the 'next' command to step over to the next source line
> pBase->hello();
>
> next
> next
> 22 pBase->hello();
>
>
> Then I use a series of 'stepi' commands to execute the machine
> instructions to 'step into' the function hello().
Note that 'stepi' command means "step one instruction" while
"step" means step into the function. If you use "step" -
does it still behave this way?
>
> stepi
> stepi
> 0x4804081c 22 pBase->hello();
> stepi
> stepi
> 0x48040820 22 pBase->hello();
> stepi
> stepi
> 0x48040824 22 pBase->hello();
> stepi
> stepi
> 0x48040828 22 pBase->hello();
> stepi
> stepi
> 0x4804082c 22 pBase->hello();
> stepi
> stepi
> 0xfe339f64 in MsgSendv () from
> /opt/qnx632/target/qnx6/ppcbe/lib/libc.so.2
>
> Here is the disassembly for the above:
>
> pBase->hello();
> 48040818: 81 3f 00 10 lwz r9,16(r31)
> 4804081c: 81 29 00 00 lwz r9,0(r9)
> 48040820: 81 29 00 00 lwz r9,0(r9)
> 48040824: 7d 29 03 a6 mtctr r9
> 48040828: 80 7f 00 10 lwz r3,16(r31)
> 4804082c: 4e 80 04 21 bctrl
>
> One interesting point, if before doing the stepi instructions above, I
> insert a breakpoint on the printf() statement in hello(), the stepi
> instructions will successfully step into the hello() function and halt
> on the printf() function call.
in this case I think you did equivalent of
(gdb) b 'Base::hello()'
This is normal.
|
|
|
|
|
|
