|
|
GDB (on PPC target) can't step into functions derived from abstract class
|
|
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
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
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
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
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
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
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
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
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
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
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
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
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
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
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
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
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
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
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.
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
02/20/2009 9:17 AM
post22610
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Yes it still behaves the same way.
-----Original Message-----
From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
Sent: Thursday, February 19, 2009 5:16 PM
To: general-toolchain
Subject: 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?
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
02/19/2009 4:33 PM
post22565
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
Robert,
I just run the test on a 6.3.2 ppc target and it still works
fine for me.
# uname -a
QNX t2ppcbe 6.3.2 2006/03/16-14:19:24EST 8555CDS ppcbe
Please make sure you are not getting any warnings about
mismatched libraries.
Thanks,
Aleksandar
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
02/19/2009 5:00 PM
post22568
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Aleksandar:
As far as I can tell I'm not getting any mismatched library warnings
from either the build process or when launching from gdb. Is there
anywhere else I should look for these warnings?
Here is the result from my uname
# uname -a
QNX localhost 6.3.2 2006/03/16-14:18:11EST WRM_782 ppcbe
robert
-----Original Message-----
From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
Sent: Thursday, February 19, 2009 4:34 PM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
Robert,
I just run the test on a 6.3.2 ppc target and it still works
fine for me.
# uname -a
QNX t2ppcbe 6.3.2 2006/03/16-14:19:24EST 8555CDS ppcbe
Please make sure you are not getting any warnings about
mismatched libraries.
Thanks,
Aleksandar
_______________________________________________
General
http://community.qnx.com/sf/go/post22565
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
02/19/2009 5:10 PM
post22570
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
Robert D'Attilio wrote:
> Aleksandar:
>
> As far as I can tell I'm not getting any mismatched library warnings
> from either the build process or when launching from gdb. Is there
> anywhere else I should look for these warnings?
If you start gdb from console, you will see it. I think it
should be visible in the ide console as well, but it may
depend on the ide version... not sure.
Try starting gdb from your shell (you can see the command
line I used).
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
02/20/2009 9:15 AM
post22609
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Aleksandar:
I tried starting gdb from the shell and don't see any warnings or errors
regarding libraries. Here is what I see:
(gdb) run
Starting program:
/home/robert/ide-4.5-workspace-782/TestBed/ppc/o-be-g/TestBed_g
Remote: /tmp/TestBed_g2
Setting Dynamic-Linker Breakpoint based on
/opt/qnx632/target/qnx6/ppcbe/usr/lib/ldqnx.so.2
Breakpoint 1, main (argc=1, argv=0x4803fed4)
at /home/robert/ide-4.5-workspace-782/TestBed/TestBed.cc:25
25 Base* pBase = new Derived();
-----Original Message-----
From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
Sent: Thursday, February 19, 2009 5:11 PM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
Robert D'Attilio wrote:
> Aleksandar:
>
> As far as I can tell I'm not getting any mismatched library warnings
> from either the build process or when launching from gdb. Is there
> anywhere else I should look for these warnings?
If you start gdb from console, you will see it. I think it
should be visible in the ide console as well, but it may
depend on the ide version... not sure.
Try starting gdb from your shell (you can see the command
line I used).
_______________________________________________
General
http://community.qnx.com/sf/go/post22570
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
02/20/2009 10:30 AM
post22628
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
Robert D'Attilio wrote:
> Aleksandar:
>
> I tried starting gdb from the shell and don't see any warnings or errors
> regarding libraries. Here is what I see:
>
> (gdb) run
> Starting program:
> /home/robert/ide-4.5-workspace-782/TestBed/ppc/o-be-g/TestBed_g
> Remote: /tmp/TestBed_g2
> Setting Dynamic-Linker Breakpoint based on
> /opt/qnx632/target/qnx6/ppcbe/usr/lib/ldqnx.so.2
>
> Breakpoint 1, main (argc=1, argv=0x4803fed4)
> at /home/robert/ide-4.5-workspace-782/TestBed/TestBed.cc:25
> 25 Base* pBase = new Derived();
>
Ok, then that part is ok.
The only way I can try to diagnose (since I can not
reproduce it locally) is if you do the following:
1) On your target, in your shell set PDEBUG_DEBUG env. variable:
# export PDEBUG_DEBUG=1
2) Start pdebug on your target but tell it to use port other
than 8000, and redirect the output into a file:
# pdebug -v 8010 > /tmp/pdebug.log 2>&1
(-v is for vrebose)
3) On your host, start gdb from your shell:
$ ntoppc-gdb <your binary on linux> --ex "target qnx <your
target hostname>:8010" --ex "upload <your binary on linux>
/tmp/test"
4) Do this simple debug session:
...
(gdb) set logging file /tmp/gdb.log
(gdb) set logging on
(gdb) set debug infrun 1
(gdb) start
...
(gdb) step
...
5) When it stops in MsgSend, or wherever it happens to land,
kill the inferior:
(gdb) kill
... answer yes
6) Start session again; this is only because pdebug seems to
not flush the output to the log file so we need more output
to push the one we want.
(gdb) start
...
(gdb) q
.... y
7) on your target, kill pdebug you sterted in step 2)
8) Attach pdebug.log from your target and gdb.log from your
host to your reply.
That should give me a clue why is it stopping there.
Thanks,
Aleksandar
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
02/20/2009 12:17 PM
post22643
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Aleksandar:
Here are the requested files.
robert
.....
8) Attach pdebug.log from your target and gdb.log from your
host to your reply.
That should give me a clue why is it stopping there.
Thanks,
Aleksandar
_______________________________________________
General
http://community.qnx.com/sf/go/post22628
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
02/20/2009 1:20 PM
post22648
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
Thanks, that will help. I forgot, however, to ask for the
executable (or disassembly).
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
02/20/2009 1:23 PM
post22649
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Here you go.
-----Original Message-----
From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
Sent: Friday, February 20, 2009 1:20 PM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
Thanks, that will help. I forgot, however, to ask for the
executable (or disassembly).
_______________________________________________
General
http://community.qnx.com/sf/go/post22648
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
02/20/2009 1:57 PM
post22653
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
Thank you Robert.
The log suggests a problem in debugging support in the
kernel. I will check with the kernel people; it would be
good if you could check which procnto are you running and
give some detail on the cpu?
To check which procnto:
# pidin -p 1
Thanks,
Aleksandar
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
02/20/2009 2:08 PM
post22654
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Aleksandar:
Okay, that's a bit of progress then.
# pidin -p 1
pid tid name prio STATE Blocked
1 1 procnto 0f READY
1 2 procnto 255r RECEIVE 1
1 3 procnto 255r RECEIVE 1
1 4 procnto 11r RECEIVE 1
1 5 procnto 10r RECEIVE 1
1 6 procnto 40r RECEIVE 1
1 7 procnto 10r RECEIVE 1
1 8 procnto 20r RECEIVE 1
1 9 procnto 10r RUNNING
1 10 procnto 40r RECEIVE 1
As for the processor, it's an AMCC PPC405EP processor.
Cheers
Robert
-----Original Message-----
From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
Sent: Friday, February 20, 2009 1:57 PM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
Thank you Robert.
The log suggests a problem in debugging support in the
kernel. I will check with the kernel people; it would be
good if you could check which procnto are you running and
give some detail on the cpu?
To check which procnto:
# pidin -p 1
Thanks,
Aleksandar
_______________________________________________
General
http://community.qnx.com/sf/go/post22653
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
02/24/2009 10:09 AM
post22826
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Aleksandar:
Any news yet from the kernel people?
robert
-----Original Message-----
From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
Sent: Friday, February 20, 2009 1:57 PM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
Thank you Robert.
The log suggests a problem in debugging support in the
kernel. I will check with the kernel people; it would be
good if you could check which procnto are you running and
give some detail on the cpu?
To check which procnto:
# pidin -p 1
Thanks,
Aleksandar
_______________________________________________
General
http://community.qnx.com/sf/go/post22653
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
02/24/2009 10:57 AM
post22831
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
Hello Robert,
Yes, there seems to be a fix that went in after 6.3.2
release. For more detail, however, we will have to wait for
the person who works on ppc debug support, who should be
back in the office next week.
Do you have a workaround for the time being? I can not,
unfortunately, suggest anything better than setting
breakpoints explicitly in functions/methods where you want
to stop.
You may also experiment with different procnto-s (for
example, even though it is a uniprocessor system, you could
try procnto-smp or one of the instrumented variants,
procnto-instr or procnto-smp-instr). It *might* give better
results. I can not reproduce the problem here, otherwise I
would have tried that myself.
Thanks,
Aleksandar
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
02/24/2009 11:36 AM
post22837
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Aleksandar:
Thanks for your help. I tried using an instrumented version of the
kernel as suggested but I get the same behaviour.
I'll wait to hear back from you when the ppc debug support person
returns.
Cheers
Robert
-----Original Message-----
From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
Sent: Tuesday, February 24, 2009 10:58 AM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
Hello Robert,
Yes, there seems to be a fix that went in after 6.3.2
release. For more detail, however, we will have to wait for
the person who works on ppc debug support, who should be
back in the office next week.
Do you have a workaround for the time being? I can not,
unfortunately, suggest anything better than setting
breakpoints explicitly in functions/methods where you want
to stop.
You may also experiment with different procnto-s (for
example, even though it is a uniprocessor system, you could
try procnto-smp or one of the instrumented variants,
procnto-instr or procnto-smp-instr). It *might* give better
results. I can not reproduce the problem here, otherwise I
would have tried that myself.
Thanks,
Aleksandar
_______________________________________________
General
http://community.qnx.com/sf/go/post22831
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
03/02/2009 1:39 PM
post23240
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
Hi Robert,
This bug was fixed after the 6.3.2 release. It was a bug in the single
step handling in the kernel.
More specifically it was an error (as you surmised) in the handling of
the bctr* instructions. It worked
for Aleksander because he was testing on a BookE processor, which has
hardware single step, whereas
you are using a 405 processor, which does not, and single step needs to
be emulated by the kernel.
Regards,
Colin
Robert D'Attilio wrote:
> Aleksandar:
>
> Thanks for your help. I tried using an instrumented version of the
> kernel as suggested but I get the same behaviour.
>
> I'll wait to hear back from you when the ppc debug support person
> returns.
>
> Cheers
> Robert
>
>
> -----Original Message-----
> From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
> Sent: Tuesday, February 24, 2009 10:58 AM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived from
> abstract class
>
> Hello Robert,
>
> Yes, there seems to be a fix that went in after 6.3.2
> release. For more detail, however, we will have to wait for
> the person who works on ppc debug support, who should be
> back in the office next week.
>
> Do you have a workaround for the time being? I can not,
> unfortunately, suggest anything better than setting
> breakpoints explicitly in functions/methods where you want
> to stop.
>
> You may also experiment with different procnto-s (for
> example, even though it is a uniprocessor system, you could
> try procnto-smp or one of the instrumented variants,
> procnto-instr or procnto-smp-instr). It *might* give better
> results. I can not reproduce the problem here, otherwise I
> would have tried that myself.
>
> Thanks,
>
> Aleksandar
>
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post22831
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post22837
>
>
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
03/02/2009 3:04 PM
post23252
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Colin:
Thanks for confirming my observations.
Can I get the fix in a patched version of procnto (I'm assuming that's
what I would need)? If so, where would I find it on the website?
Thanks
Robert
-----Original Message-----
From: Colin Burgess [mailto:community-noreply@qnx.com]
Sent: Monday, March 02, 2009 1:40 PM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
Hi Robert,
This bug was fixed after the 6.3.2 release. It was a bug in the single
step handling in the kernel.
More specifically it was an error (as you surmised) in the handling of
the bctr* instructions. It worked
for Aleksander because he was testing on a BookE processor, which has
hardware single step, whereas
you are using a 405 processor, which does not, and single step needs to
be emulated by the kernel.
Regards,
Colin
Robert D'Attilio wrote:
> Aleksandar:
>
> Thanks for your help. I tried using an instrumented version of the
> kernel as suggested but I get the same behaviour.
>
> I'll wait to hear back from you when the ppc debug support person
> returns.
>
> Cheers
> Robert
>
>
> -----Original Message-----
> From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
> Sent: Tuesday, February 24, 2009 10:58 AM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived
from
> abstract class
>
> Hello Robert,
>
> Yes, there seems to be a fix that went in after 6.3.2
> release. For more detail, however, we will have to wait for
> the person who works on ppc debug support, who should be
> back in the office next week.
>
> Do you have a workaround for the time being? I can not,
> unfortunately, suggest anything better than setting
> breakpoints explicitly in functions/methods where you want
> to stop.
>
> You may also experiment with different procnto-s (for
> example, even though it is a uniprocessor system, you could
> try procnto-smp or one of the instrumented variants,
> procnto-instr or procnto-smp-instr). It *might* give better
> results. I can not reproduce the problem here, otherwise I
> would have tried that myself.
>
> Thanks,
>
> Aleksandar
>
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post22831
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post22837
>
>
_______________________________________________
General
http://community.qnx.com/sf/go/post23240
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
03/02/2009 3:26 PM
post23257
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
You can try these - "standard disclaimer" - these are completely
unofficial, untested versions. I would not use them
in a product.
If you need a supported kernel then you would have to request a Priority
Support Patch via sales.
Regards,
Colin
Robert D'Attilio wrote:
> Colin:
>
> Thanks for confirming my observations.
>
> Can I get the fix in a patched version of procnto (I'm assuming that's
> what I would need)? If so, where would I find it on the website?
>
> Thanks
> Robert
>
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: Monday, March 02, 2009 1:40 PM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived from
> abstract class
>
> Hi Robert,
>
> This bug was fixed after the 6.3.2 release. It was a bug in the single
> step handling in the kernel.
>
> More specifically it was an error (as you surmised) in the handling of
> the bctr* instructions. It worked
> for Aleksander because he was testing on a BookE processor, which has
> hardware single step, whereas
> you are using a 405 processor, which does not, and single step needs to
> be emulated by the kernel.
>
> Regards,
>
> Colin
>
> Robert D'Attilio wrote:
>
>> Aleksandar:
>>
>> Thanks for your help. I tried using an instrumented version of the
>> kernel as suggested but I get the same behaviour.
>>
>> I'll wait to hear back from you when the ppc debug support person
>> returns.
>>
>> Cheers
>> Robert
>>
>>
>> -----Original Message-----
>> From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
>> Sent: Tuesday, February 24, 2009 10:58 AM
>> To: general-toolchain
>> Subject: Re: GDB (on PPC target) can't step into functions derived
>>
> from
>
>> abstract class
>>
>> Hello Robert,
>>
>> Yes, there seems to be a fix that went in after 6.3.2
>> release. For more detail, however, we will have to wait for
>> the person who works on ppc debug support, who should be
>> back in the office next week.
>>
>> Do you have a workaround for the time being? I can not,
>> unfortunately, suggest anything better than setting
>> breakpoints explicitly in functions/methods where you want
>> to stop.
>>
>> You may also experiment with different procnto-s (for
>> example, even though it is a uniprocessor system, you could
>> try procnto-smp or one of the instrumented variants,
>> procnto-instr or procnto-smp-instr). It *might* give better
>> results. I can not reproduce the problem here, otherwise I
>> would have tried that myself.
>>
>> Thanks,
>>
>> Aleksandar
>>
>>
>>
>>
>> _______________________________________________
>> General
>> http://community.qnx.com/sf/go/post22831
>>
>>
>> _______________________________________________
>> General
>> http://community.qnx.com/sf/go/post22837
>>
>>
>>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23240
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23252
>
>
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
03/02/2009 3:48 PM
post23267
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Colin:
Thanks I'll give these a try. Do you know if there is a way I can build
my image to pick-up these 'patched' procnto's i.e. I'm assuming I would
have to modify my buildifs but not sure how to specify the non-standard
version of procnto to role into my image.
As for an official fix, can you confirm if this is fixed in the 6.4
release?
Cheers,
Robert
-----Original Message-----
From: Colin Burgess [mailto:community-noreply@qnx.com]
Sent: Monday, March 02, 2009 3:27 PM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
You can try these - "standard disclaimer" - these are completely
unofficial, untested versions. I would not use them
in a product.
If you need a supported kernel then you would have to request a Priority
Support Patch via sales.
Regards,
Colin
Robert D'Attilio wrote:
> Colin:
>
> Thanks for confirming my observations.
>
> Can I get the fix in a patched version of procnto (I'm assuming that's
> what I would need)? If so, where would I find it on the website?
>
> Thanks
> Robert
>
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: Monday, March 02, 2009 1:40 PM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived
from
> abstract class
>
> Hi Robert,
>
> This bug was fixed after the 6.3.2 release. It was a bug in the
single
> step handling in the kernel.
>
> More specifically it was an error (as you surmised) in the handling of
> the bctr* instructions. It worked
> for Aleksander because he was testing on a BookE processor, which has
> hardware single step, whereas
> you are using a 405 processor, which does not, and single step needs
to
> be emulated by the kernel.
>
> Regards,
>
> Colin
>
> Robert D'Attilio wrote:
>
>> Aleksandar:
>>
>> Thanks for your help. I tried using an instrumented version of the
>> kernel as suggested but I get the same behaviour.
>>
>> I'll wait to hear back from you when the ppc debug support person
>> returns.
>>
>> Cheers
>> Robert
>>
>>
>> -----Original Message-----
>> From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
>> Sent: Tuesday, February 24, 2009 10:58 AM
>> To: general-toolchain
>> Subject: Re: GDB (on PPC target) can't step into functions derived
>>
> from
>
>> abstract class
>>
>> Hello Robert,
>>
>> Yes, there seems to be a fix that went in after 6.3.2
>> release. For more detail, however, we will have to wait for
>> the person who works on ppc debug support, who should be
>> back in the office next week.
>>
>> Do you have a workaround for the time being? I can not,
>> unfortunately, suggest anything better than setting
>> breakpoints explicitly in functions/methods where you want
>> to stop.
>>
>> You may also experiment with different procnto-s (for
>> example, even though it is a uniprocessor system, you could
>> try procnto-smp or one of the instrumented variants,
>> procnto-instr or procnto-smp-instr). It *might* give better
>> results. I can not reproduce the problem here, otherwise I
>> would have tried that myself.
>>
>> Thanks,
>>
>> Aleksandar
>>
>>
>>
>>
>> _______________________________________________
>> General
>> http://community.qnx.com/sf/go/post22831
>>
>>
>> _______________________________________________
>> General
>> http://community.qnx.com/sf/go/post22837
>>
>>
>>
>
>...
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
03/02/2009 3:49 PM
post23269
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
I'm not sure how to convince the system builder to do it - maybe an IDE
person can comment?
Yes, it is fixed in the 6.4.0 release.
Regards,
Colin
Robert D'Attilio wrote:
> Colin:
>
> Thanks I'll give these a try. Do you know if there is a way I can build
> my image to pick-up these 'patched' procnto's i.e. I'm assuming I would
> have to modify my buildifs but not sure how to specify the non-standard
> version of procnto to role into my image.
>
> As for an official fix, can you confirm if this is fixed in the 6.4
> release?
>
> Cheers,
> Robert
>
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: Monday, March 02, 2009 3:27 PM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived from
> abstract class
>
> You can try these - "standard disclaimer" - these are completely
> unofficial, untested versions. I would not use them
> in a product.
>
> If you need a supported kernel then you would have to request a Priority
>
> Support Patch via sales.
>
> Regards,
>
> Colin
>
> Robert D'Attilio wrote:
>
>> Colin:
>>
>> Thanks for confirming my observations.
>>
>> Can I get the fix in a patched version of procnto (I'm assuming that's
>> what I would need)? If so, where would I find it on the website?
>>
>> Thanks
>> Robert
>>
>> -----Original Message-----
>> From: Colin Burgess [mailto:community-noreply@qnx.com]
>> Sent: Monday, March 02, 2009 1:40 PM
>> To: general-toolchain
>> Subject: Re: GDB (on PPC target) can't step into functions derived
>>
> from
>
>> abstract class
>>
>> Hi Robert,
>>
>> This bug was fixed after the 6.3.2 release. It was a bug in the
>>
> single
>
>> step handling in the kernel.
>>
>> More specifically it was an error (as you surmised) in the handling of
>>
>
>
>> the bctr* instructions. It worked
>> for Aleksander because he was testing on a BookE processor, which has
>> hardware single step, whereas
>> you are using a 405 processor, which does not, and single step needs
>>
> to
>
>> be emulated by the kernel.
>>
>> Regards,
>>
>> Colin
>>
>> Robert D'Attilio wrote:
>>
>>
>>> Aleksandar:
>>>
>>> Thanks for your help. I tried using an instrumented version of the
>>> kernel as suggested but I get the same behaviour.
>>>
>>> I'll wait to hear back from you when the ppc debug support person
>>> returns.
>>>
>>> Cheers
>>> Robert
>>>
>>>
>>> -----Original Message-----
>>> From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
>>> Sent: Tuesday, February 24, 2009 10:58 AM
>>> To: general-toolchain
>>> Subject: Re: GDB (on PPC target) can't step into functions derived
>>>
>>>
>> from
>>
>>
>>> abstract class
>>>
>>> Hello Robert,
>>>
>>> Yes, there seems to be a fix that went in after 6.3.2
>>> release. For more detail, however, we will have to wait for
>>> the person who works on ppc debug support, who should be
>>> back in the office next week.
>>>
>>> Do you have a workaround for the time being? I can not,
>>> unfortunately, suggest anything better than setting
>>> breakpoints explicitly in functions/methods where you want
>>> to stop.
>>>
>>>...
View Full Message
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
03/03/2009 2:05 PM
post23383
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
In image properties user can pick up any from combo box. Just before
doing your selection add customized procnto location to system searcch
path (See SB project properties ->Search Paths->System Files Tab
On 02/03/2009 3:49 PM, Colin Burgess wrote:
> I'm not sure how to convince the system builder to do it - maybe an IDE
> person can comment?
>
> Yes, it is fixed in the 6.4.0 release.
>
> Regards,
>
> Colin
>
> Robert D'Attilio wrote:
>
>> Colin:
>>
>> Thanks I'll give these a try. Do you know if there is a way I can build
>> my image to pick-up these 'patched' procnto's i.e. I'm assuming I would
>> have to modify my buildifs but not sure how to specify the non-standard
>> version of procnto to role into my image.
>>
>> As for an official fix, can you confirm if this is fixed in the 6.4
>> release?
>>
>> Cheers,
>> Robert
>>
>> -----Original Message-----
>> From: Colin Burgess [mailto:community-noreply@qnx.com]
>> Sent: Monday, March 02, 2009 3:27 PM
>> To: general-toolchain
>> Subject: Re: GDB (on PPC target) can't step into functions derived from
>> abstract class
>>
>> You can try these - "standard disclaimer" - these are completely
>> unofficial, untested versions. I would not use them
>> in a product.
>>
>> If you need a supported kernel then you would have to request a Priority
>>
>> Support Patch via sales.
>>
>> Regards,
>>
>> Colin
>>
>> Robert D'Attilio wrote:
>>
>>
>>> Colin:
>>>
>>> Thanks for confirming my observations.
>>>
>>> Can I get the fix in a patched version of procnto (I'm assuming that's
>>> what I would need)? If so, where would I find it on the website?
>>>
>>> Thanks
>>> Robert
>>>
>>> -----Original Message-----
>>> From: Colin Burgess [mailto:community-noreply@qnx.com]
>>> Sent: Monday, March 02, 2009 1:40 PM
>>> To: general-toolchain
>>> Subject: Re: GDB (on PPC target) can't step into functions derived
>>>
>>>
>> from
>>
>>
>>> abstract class
>>>
>>> Hi Robert,
>>>
>>> This bug was fixed after the 6.3.2 release. It was a bug in the
>>>
>>>
>> single
>>
>>
>>> step handling in the kernel.
>>>
>>> More specifically it was an error (as you surmised) in the handling of
>>>
>>>
>>
>>
>>> the bctr* instructions. It worked
>>> for Aleksander because he was testing on a BookE processor, which has
>>> hardware single step, whereas
>>> you are using a 405 processor, which does not, and single step needs
>>>
>>>
>> to
>>
>>
>>> be emulated by the kernel.
>>>
>>> Regards,
>>>
>>> Colin
>>>
>>> Robert D'Attilio wrote:
>>>
>>>
>>>
>>>> Aleksandar:
>>>>
>>>> Thanks for your help. I tried using an instrumented version of the
>>>> kernel as suggested but I get the same behaviour.
>>>>
>>>> I'll wait to hear back from you when the ppc debug support person
>>>> returns.
>>>>
>>>> Cheers
>>>> Robert
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
>>>> Sent: Tuesday, February 24,...
View Full Message
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
03/03/2009 2:20 PM
post23387
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Alex:
Unfortuantely, we don't use the system builder feature from the IDE to
build our system image. We run mkifs on our buildifs file to generate
the image. Any idea what to change in my buildifs then?
Thanks
robert
-----Original Message-----
From: Alex Chapiro [mailto:community-noreply@qnx.com]
Sent: Tuesday, March 03, 2009 2:05 PM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
In image properties user can pick up any from combo box. Just before
doing your selection add customized procnto location to system searcch
path (See SB project properties ->Search Paths->System Files Tab
On 02/03/2009 3:49 PM, Colin Burgess wrote:
> I'm not sure how to convince the system builder to do it - maybe an
IDE
> person can comment?
>
> Yes, it is fixed in the 6.4.0 release.
>
> Regards,
>
> Colin
>
> Robert D'Attilio wrote:
>
>> Colin:
>>
>> Thanks I'll give these a try. Do you know if there is a way I can
build
>> my image to pick-up these 'patched' procnto's i.e. I'm assuming I
would
>> have to modify my buildifs but not sure how to specify the
non-standard
>> version of procnto to role into my image.
>>
>> As for an official fix, can you confirm if this is fixed in the 6.4
>> release?
>>
>> Cheers,
>> Robert
>>
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
03/03/2009 2:26 PM
post23388
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
Just change the procnto-400 in your buildifs file to be the fullpath of
the new procnto-400 I gave you.
Cheers,
Colin
Robert D'Attilio wrote:
> Alex:
>
> Unfortuantely, we don't use the system builder feature from the IDE to
> build our system image. We run mkifs on our buildifs file to generate
> the image. Any idea what to change in my buildifs then?
>
> Thanks
> robert
>
> -----Original Message-----
> From: Alex Chapiro [mailto:community-noreply@qnx.com]
> Sent: Tuesday, March 03, 2009 2:05 PM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived from
> abstract class
>
> In image properties user can pick up any from combo box. Just before
> doing your selection add customized procnto location to system searcch
> path (See SB project properties ->Search Paths->System Files Tab
>
> On 02/03/2009 3:49 PM, Colin Burgess wrote:
>
>> I'm not sure how to convince the system builder to do it - maybe an
>>
> IDE
>
>> person can comment?
>>
>> Yes, it is fixed in the 6.4.0 release.
>>
>> Regards,
>>
>> Colin
>>
>> Robert D'Attilio wrote:
>>
>>
>>> Colin:
>>>
>>> Thanks I'll give these a try. Do you know if there is a way I can
>>>
> build
>
>>> my image to pick-up these 'patched' procnto's i.e. I'm assuming I
>>>
> would
>
>>> have to modify my buildifs but not sure how to specify the
>>>
> non-standard
>
>>> version of procnto to role into my image.
>>>
>>> As for an official fix, can you confirm if this is fixed in the 6.4
>>> release?
>>>
>>> Cheers,
>>> Robert
>>>
>>>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23387
>
>
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
03/03/2009 2:51 PM
post23396
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Colin:
Okay, I did that and built a new image with the modified procnto image
you provided. However I still get the same behaviour with the debugger.
Can you confirm if you sent the correct procnto binaries? Is there a
version number I can check on my end?
Cheers
Robert
-----Original Message-----
From: Colin Burgess [mailto:community-noreply@qnx.com]
Sent: Tuesday, March 03, 2009 2:27 PM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
Just change the procnto-400 in your buildifs file to be the fullpath of
the new procnto-400 I gave you.
Cheers,
Colin
Robert D'Attilio wrote:
> Alex:
>
> Unfortuantely, we don't use the system builder feature from the IDE to
> build our system image. We run mkifs on our buildifs file to generate
> the image. Any idea what to change in my buildifs then?
>
> Thanks
> robert
>
> -----Original Message-----
> From: Alex Chapiro [mailto:community-noreply@qnx.com]
> Sent: Tuesday, March 03, 2009 2:05 PM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived
from
> abstract class
>
> In image properties user can pick up any from combo box. Just before
> doing your selection add customized procnto location to system searcch
> path (See SB project properties ->Search Paths->System Files Tab
>
> On 02/03/2009 3:49 PM, Colin Burgess wrote:
>
>> I'm not sure how to convince the system builder to do it - maybe an
>>
> IDE
>
>> person can comment?
>>
>> Yes, it is fixed in the 6.4.0 release.
>>
>> Regards,
>>
>> Colin
>>
>> Robert D'Attilio wrote:
>>
>>
>>> Colin:
>>>
>>> Thanks I'll give these a try. Do you know if there is a way I can
>>>
> build
>
>>> my image to pick-up these 'patched' procnto's i.e. I'm assuming I
>>>
> would
>
>>> have to modify my buildifs but not sure how to specify the
>>>
> non-standard
>
>>> version of procnto to role into my image.
>>>
>>> As for an official fix, can you confirm if this is fixed in the 6.4
>>> release?
>>>
>>> Cheers,
>>> Robert
>>>
>>>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23387
>
>
_______________________________________________
General
http://community.qnx.com/sf/go/post23388
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
03/03/2009 2:51 PM
post23397
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
uname -a should show the build date.
I'll double check to make sure the fix integrated ok.
Robert D'Attilio wrote:
> Colin:
>
> Okay, I did that and built a new image with the modified procnto image
> you provided. However I still get the same behaviour with the debugger.
> Can you confirm if you sent the correct procnto binaries? Is there a
> version number I can check on my end?
>
> Cheers
> Robert
>
>
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: Tuesday, March 03, 2009 2:27 PM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived from
> abstract class
>
> Just change the procnto-400 in your buildifs file to be the fullpath of
> the new procnto-400 I gave you.
>
> Cheers,
>
> Colin
>
>
>
> Robert D'Attilio wrote:
>
>> Alex:
>>
>> Unfortuantely, we don't use the system builder feature from the IDE to
>> build our system image. We run mkifs on our buildifs file to generate
>> the image. Any idea what to change in my buildifs then?
>>
>> Thanks
>> robert
>>
>> -----Original Message-----
>> From: Alex Chapiro [mailto:community-noreply@qnx.com]
>> Sent: Tuesday, March 03, 2009 2:05 PM
>> To: general-toolchain
>> Subject: Re: GDB (on PPC target) can't step into functions derived
>>
> from
>
>> abstract class
>>
>> In image properties user can pick up any from combo box. Just before
>> doing your selection add customized procnto location to system searcch
>>
>
>
>> path (See SB project properties ->Search Paths->System Files Tab
>>
>> On 02/03/2009 3:49 PM, Colin Burgess wrote:
>>
>>
>>> I'm not sure how to convince the system builder to do it - maybe an
>>>
>>>
>> IDE
>>
>>
>>> person can comment?
>>>
>>> Yes, it is fixed in the 6.4.0 release.
>>>
>>> Regards,
>>>
>>> Colin
>>>
>>> Robert D'Attilio wrote:
>>>
>>>
>>>
>>>> Colin:
>>>>
>>>> Thanks I'll give these a try. Do you know if there is a way I can
>>>>
>>>>
>> build
>>
>>
>>>> my image to pick-up these 'patched' procnto's i.e. I'm assuming I
>>>>
>>>>
>> would
>>
>>
>>>> have to modify my buildifs but not sure how to specify the
>>>>
>>>>
>> non-standard
>>
>>
>>>> version of procnto to role into my image.
>>>>
>>>> As for an official fix, can you confirm if this is fixed in the 6.4
>>>> release?
>>>>
>>>> Cheers,
>>>> Robert
>>>>
>>>>
>>>>
>> _______________________________________________
>> General
>> http://community.qnx.com/sf/go/post23387
>>
>>
>>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23388
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23396
>
>
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
03/03/2009 3:17 PM
post23401
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
This is what I get when I link in your procnto-400-instr
# uname -a
QNX localhost 6.3.2 2009/03/02-15:28:31EST WRM_782 ppcbe
-----Original Message-----
From: Colin Burgess [mailto:community-noreply@qnx.com]
Sent: Tuesday, March 03, 2009 2:52 PM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
uname -a should show the build date.
I'll double check to make sure the fix integrated ok.
Robert D'Attilio wrote:
> Colin:
>
> Okay, I did that and built a new image with the modified procnto image
> you provided. However I still get the same behaviour with the
debugger.
> Can you confirm if you sent the correct procnto binaries? Is there a
> version number I can check on my end?
>
> Cheers
> Robert
>
>
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
03/03/2009 3:34 PM
post23402
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
Ok, nuts. I finallly tracked down a 405 and the issue still happens
with 6.4.0, so the fix
we saw wasn't actually the issue after all...
*SIGH*
Robert D'Attilio wrote:
> This is what I get when I link in your procnto-400-instr
>
> # uname -a
> QNX localhost 6.3.2 2009/03/02-15:28:31EST WRM_782 ppcbe
>
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: Tuesday, March 03, 2009 2:52 PM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived from
> abstract class
>
> uname -a should show the build date.
>
> I'll double check to make sure the fix integrated ok.
>
> Robert D'Attilio wrote:
>
>> Colin:
>>
>> Okay, I did that and built a new image with the modified procnto image
>> you provided. However I still get the same behaviour with the
>>
> debugger.
>
>> Can you confirm if you sent the correct procnto binaries? Is there a
>> version number I can check on my end?
>>
>> Cheers
>> Robert
>>
>>
>>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23401
>
>
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
03/03/2009 4:03 PM
post23404
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Bummer. So should I submit a ticket to get it fixed then?
-----Original Message-----
From: Colin Burgess [mailto:community-noreply@qnx.com]
Sent: Tuesday, March 03, 2009 3:34 PM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
Ok, nuts. I finallly tracked down a 405 and the issue still happens
with 6.4.0, so the fix
we saw wasn't actually the issue after all...
*SIGH*
Robert D'Attilio wrote:
> This is what I get when I link in your procnto-400-instr
>
> # uname -a
> QNX localhost 6.3.2 2009/03/02-15:28:31EST WRM_782 ppcbe
>
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: Tuesday, March 03, 2009 2:52 PM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived
from
> abstract class
>
> uname -a should show the build date.
>
> I'll double check to make sure the fix integrated ok.
>
> Robert D'Attilio wrote:
>
>> Colin:
>>
>> Okay, I did that and built a new image with the modified procnto
image
>> you provided. However I still get the same behaviour with the
>>
> debugger.
>
>> Can you confirm if you sent the correct procnto binaries? Is there a
>> version number I can check on my end?
>>
>> Cheers
>> Robert
>>
>>
>>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23401
>
>
_______________________________________________
General
http://community.qnx.com/sf/go/post23402
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
03/03/2009 4:26 PM
post23405
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
I'm taking a quick look see....
Robert D'Attilio wrote:
> Bummer. So should I submit a ticket to get it fixed then?
>
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: Tuesday, March 03, 2009 3:34 PM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived from
> abstract class
>
> Ok, nuts. I finallly tracked down a 405 and the issue still happens
> with 6.4.0, so the fix
> we saw wasn't actually the issue after all...
>
> *SIGH*
>
> Robert D'Attilio wrote:
>
>> This is what I get when I link in your procnto-400-instr
>>
>> # uname -a
>> QNX localhost 6.3.2 2009/03/02-15:28:31EST WRM_782 ppcbe
>>
>> -----Original Message-----
>> From: Colin Burgess [mailto:community-noreply@qnx.com]
>> Sent: Tuesday, March 03, 2009 2:52 PM
>> To: general-toolchain
>> Subject: Re: GDB (on PPC target) can't step into functions derived
>>
> from
>
>> abstract class
>>
>> uname -a should show the build date.
>>
>> I'll double check to make sure the fix integrated ok.
>>
>> Robert D'Attilio wrote:
>>
>>
>>> Colin:
>>>
>>> Okay, I did that and built a new image with the modified procnto
>>>
> image
>
>>> you provided. However I still get the same behaviour with the
>>>
>>>
>> debugger.
>>
>>
>>> Can you confirm if you sent the correct procnto binaries? Is there a
>>> version number I can check on my end?
>>>
>>> Cheers
>>> Robert
>>>
>>>
>>>
>>>
>> _______________________________________________
>> General
>> http://community.qnx.com/sf/go/post23401
>>
>>
>>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23402
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23404
>
>
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
03/04/2009 9:22 AM
post23461
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
FYI I've raised PR66008 to track this.
Robert D'Attilio wrote:
> Bummer. So should I submit a ticket to get it fixed then?
>
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: Tuesday, March 03, 2009 3:34 PM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived from
> abstract class
>
> Ok, nuts. I finallly tracked down a 405 and the issue still happens
> with 6.4.0, so the fix
> we saw wasn't actually the issue after all...
>
> *SIGH*
>
> Robert D'Attilio wrote:
>> This is what I get when I link in your procnto-400-instr
>>
>> # uname -a
>> QNX localhost 6.3.2 2009/03/02-15:28:31EST WRM_782 ppcbe
>>
>> -----Original Message-----
>> From: Colin Burgess [mailto:community-noreply@qnx.com]
>> Sent: Tuesday, March 03, 2009 2:52 PM
>> To: general-toolchain
>> Subject: Re: GDB (on PPC target) can't step into functions derived
> from
>> abstract class
>>
>> uname -a should show the build date.
>>
>> I'll double check to make sure the fix integrated ok.
>>
>> Robert D'Attilio wrote:
>>
>>> Colin:
>>>
>>> Okay, I did that and built a new image with the modified procnto
> image
>>> you provided. However I still get the same behaviour with the
>>>
>> debugger.
>>
>>> Can you confirm if you sent the correct procnto binaries? Is there a
>>> version number I can check on my end?
>>>
>>> Cheers
>>> Robert
>>>
>>>
>>>
>> _______________________________________________
>> General
>> http://community.qnx.com/sf/go/post23401
>>
>>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23402
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23404
>
--
cburgess@qnx.com
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
03/05/2009 9:07 AM
post23590
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Colin:
Is it possible (for me) to track this PR so I can see when and in what
release it gets resolved in?
Thanks again
Robert
-----Original Message-----
From: Colin Burgess [mailto:community-noreply@qnx.com]
Sent: Wednesday, March 04, 2009 9:23 AM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
FYI I've raised PR66008 to track this.
Robert D'Attilio wrote:
> Bummer. So should I submit a ticket to get it fixed then?
>
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: Tuesday, March 03, 2009 3:34 PM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived
from
> abstract class
>
> Ok, nuts. I finallly tracked down a 405 and the issue still happens
> with 6.4.0, so the fix
> we saw wasn't actually the issue after all...
>
> *SIGH*
>
> Robert D'Attilio wrote:
>> This is what I get when I link in your procnto-400-instr
>>
>> # uname -a
>> QNX localhost 6.3.2 2009/03/02-15:28:31EST WRM_782 ppcbe
>>
>> -----Original Message-----
>> From: Colin Burgess [mailto:community-noreply@qnx.com]
>> Sent: Tuesday, March 03, 2009 2:52 PM
>> To: general-toolchain
>> Subject: Re: GDB (on PPC target) can't step into functions derived
> from
>> abstract class
>>
>> uname -a should show the build date.
>>
>> I'll double check to make sure the fix integrated ok.
>>
>> Robert D'Attilio wrote:
>>
>>> Colin:
>>>
>>> Okay, I did that and built a new image with the modified procnto
> image
>>> you provided. However I still get the same behaviour with the
>>>
>> debugger.
>>
>>> Can you confirm if you sent the correct procnto binaries? Is there a
>>> version number I can check on my end?
>>>
>>> Cheers
>>> Robert
>>>
>>>
>>>
>> _______________________________________________
>> General
>> http://community.qnx.com/sf/go/post23401
>>
>>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23402
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23404
>
--
cburgess@qnx.com
_______________________________________________
General
http://community.qnx.com/sf/go/post23461
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
03/05/2009 9:11 AM
post23592
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
Unfortunately not. We'll keep you updated though.
Regareds,
Colin
Robert D'Attilio wrote:
> Colin:
>
> Is it possible (for me) to track this PR so I can see when and in what
> release it gets resolved in?
>
> Thanks again
> Robert
>
>
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: Wednesday, March 04, 2009 9:23 AM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived from
> abstract class
>
> FYI I've raised PR66008 to track this.
>
> Robert D'Attilio wrote:
>> Bummer. So should I submit a ticket to get it fixed then?
>>
>> -----Original Message-----
>> From: Colin Burgess [mailto:community-noreply@qnx.com]
>> Sent: Tuesday, March 03, 2009 3:34 PM
>> To: general-toolchain
>> Subject: Re: GDB (on PPC target) can't step into functions derived
> from
>> abstract class
>>
>> Ok, nuts. I finallly tracked down a 405 and the issue still happens
>> with 6.4.0, so the fix
>> we saw wasn't actually the issue after all...
>>
>> *SIGH*
>>
>> Robert D'Attilio wrote:
>>> This is what I get when I link in your procnto-400-instr
>>>
>>> # uname -a
>>> QNX localhost 6.3.2 2009/03/02-15:28:31EST WRM_782 ppcbe
>>>
>>> -----Original Message-----
>>> From: Colin Burgess [mailto:community-noreply@qnx.com]
>>> Sent: Tuesday, March 03, 2009 2:52 PM
>>> To: general-toolchain
>>> Subject: Re: GDB (on PPC target) can't step into functions derived
>> from
>>> abstract class
>>>
>>> uname -a should show the build date.
>>>
>>> I'll double check to make sure the fix integrated ok.
>>>
>>> Robert D'Attilio wrote:
>>>
>>>> Colin:
>>>>
>>>> Okay, I did that and built a new image with the modified procnto
>> image
>>>> you provided. However I still get the same behaviour with the
>>>>
>>> debugger.
>>>
>>>> Can you confirm if you sent the correct procnto binaries? Is there a
>>>> version number I can check on my end?
>>>>
>>>> Cheers
>>>> Robert
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> General
>>> http://community.qnx.com/sf/go/post23401
>>>
>>>
>> _______________________________________________
>> General
>> http://community.qnx.com/sf/go/post23402
>>
>>
>> _______________________________________________
>> General
>> http://community.qnx.com/sf/go/post23404
>>
>
--
cburgess@qnx.com
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from
abstract class
|
|
03/05/2009 1:13 PM
post23642
|
Re: GDB (on PPC target) can't step into functions derived from
abstract class
Just FYI, I have a candidate fix and am testing it now.
On Thu, 2009-03-05 at 09:11 -0500, Colin Burgess wrote:
> Unfortunately not. We'll keep you updated though.
>
> Regareds,
>
> Colin
>
> Robert D'Attilio wrote:
> > Colin:
> >
> > Is it possible (for me) to track this PR so I can see when and in what
> > release it gets resolved in?
> >
> > Thanks again
> > Robert
> >
> >
> > -----Original Message-----
> > From: Colin Burgess [mailto:community-noreply@qnx.com]
> > Sent: Wednesday, March 04, 2009 9:23 AM
> > To: general-toolchain
> > Subject: Re: GDB (on PPC target) can't step into functions derived from
> > abstract class
> >
> > FYI I've raised PR66008 to track this.
> >
> > Robert D'Attilio wrote:
> >> Bummer. So should I submit a ticket to get it fixed then?
> >>
> >> -----Original Message-----
> >> From: Colin Burgess [mailto:community-noreply@qnx.com]
> >> Sent: Tuesday, March 03, 2009 3:34 PM
> >> To: general-toolchain
> >> Subject: Re: GDB (on PPC target) can't step into functions derived
> > from
> >> abstract class
> >>
> >> Ok, nuts. I finallly tracked down a 405 and the issue still happens
> >> with 6.4.0, so the fix
> >> we saw wasn't actually the issue after all...
> >>
> >> *SIGH*
> >>
> >> Robert D'Attilio wrote:
> >>> This is what I get when I link in your procnto-400-instr
> >>>
> >>> # uname -a
> >>> QNX localhost 6.3.2 2009/03/02-15:28:31EST WRM_782 ppcbe
> >>>
> >>> -----Original Message-----
> >>> From: Colin Burgess [mailto:community-noreply@qnx.com]
> >>> Sent: Tuesday, March 03, 2009 2:52 PM
> >>> To: general-toolchain
> >>> Subject: Re: GDB (on PPC target) can't step into functions derived
> >> from
> >>> abstract class
> >>>
> >>> uname -a should show the build date.
> >>>
> >>> I'll double check to make sure the fix integrated ok.
> >>>
> >>> Robert D'Attilio wrote:
> >>>
> >>>> Colin:
> >>>>
> >>>> Okay, I did that and built a new image with the modified procnto
> >> image
> >>>> you provided. However I still get the same behaviour with the
> >>>>
> >>> debugger.
> >>>
> >>>> Can you confirm if you sent the correct procnto binaries? Is there a
> >>>> version number I can check on my end?
> >>>>
> >>>> Cheers
> >>>> Robert
> >>>>
> >>>>
> >>>>
> >>> _______________________________________________
> >>> General
> >>> http://community.qnx.com/sf/go/post23401
> >>>
> >>>
> >> _______________________________________________
> >> General
> >> http://community.qnx.com/sf/go/post23402
> >>
> >>
> >> _______________________________________________
> >> General
> >> http://community.qnx.com/sf/go/post23404
> >>
> >
>
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract class
|
|
03/05/2009 4:52 PM
post23721
|
Re: GDB (on PPC target) can't step into functions derived from abstract class
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract class
|
|
03/11/2009 5:27 PM
post24188
|
Re: GDB (on PPC target) can't step into functions derived from abstract class
I've attached patched versions of 6.3.2GA PPC 400 kernels for you to try. These are unofficial, unsupported engineering
releases and we would council against using them in a production system.
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
03/12/2009 4:38 PM
post24274
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Neil:
The patch seems to be working fine now.
Many thanks
Robert
-----Original Message-----
From: Neil Schellenberger [mailto:community-noreply@qnx.com]
Sent: Wednesday, March 11, 2009 5:28 PM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
I've attached patched versions of 6.3.2GA PPC 400 kernels for you to
try. These are unofficial, unsupported engineering releases and we
would council against using them in a production system.
_______________________________________________
General
http://community.qnx.com/sf/go/post24188
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from
abstract class
|
|
03/12/2009 4:46 PM
post24275
|
RE: GDB (on PPC target) can't step into functions derived from
abstract class
Hi Robert,
That's excellent news! I'll do the formal backports to 6.3.2 and to
6.4.0.1 and close the PR, if that's OK with you.
Regards,
Neil
On Thu, 2009-03-12 at 16:38 -0400, Robert D'Attilio wrote:
> Neil:
>
> The patch seems to be working fine now.
>
> Many thanks
> Robert
>
> -----Original Message-----
> From: Neil Schellenberger [mailto:community-noreply@qnx.com]
> Sent: Wednesday, March 11, 2009 5:28 PM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived from
> abstract class
>
> I've attached patched versions of 6.3.2GA PPC 400 kernels for you to
> try. These are unofficial, unsupported engineering releases and we
> would council against using them in a production system.
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post24188
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post24274
>
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
03/13/2009 10:50 AM
post24325
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Sounds good to me.
Will there be some notification when I can pick up the official 6.3.2
patch? Also where would I download it from?
Cheers
Robert
-----Original Message-----
From: Neil Schellenberger [mailto:community-noreply@qnx.com]
Sent: Thursday, March 12, 2009 4:46 PM
To: general-toolchain
Subject: RE: GDB (on PPC target) can't step into functions derived from
abstract class
Hi Robert,
That's excellent news! I'll do the formal backports to 6.3.2 and to
6.4.0.1 and close the PR, if that's OK with you.
Regards,
Neil
On Thu, 2009-03-12 at 16:38 -0400, Robert D'Attilio wrote:
> Neil:
>
> The patch seems to be working fine now.
>
> Many thanks
> Robert
>
> -----Original Message-----
> From: Neil Schellenberger [mailto:community-noreply@qnx.com]
> Sent: Wednesday, March 11, 2009 5:28 PM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived
from
> abstract class
>
> I've attached patched versions of 6.3.2GA PPC 400 kernels for you to
> try. These are unofficial, unsupported engineering releases and we
> would council against using them in a production system.
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post24188
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post24274
>
_______________________________________________
General
http://community.qnx.com/sf/go/post24275
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from
abstract class
|
|
03/13/2009 4:17 PM
post24369
|
RE: GDB (on PPC target) can't step into functions derived from
abstract class
Hi Robert,
You can request Priority Support Patches for 6.3.2 through your Customer
Support Representative.
Regards,
Neil
On Fri, 2009-03-13 at 10:50 -0400, Robert D'Attilio wrote:
> Sounds good to me.
>
> Will there be some notification when I can pick up the official 6.3.2
> patch? Also where would I download it from?
>
> Cheers
> Robert
>
> -----Original Message-----
> From: Neil Schellenberger [mailto:community-noreply@qnx.com]
> Sent: Thursday, March 12, 2009 4:46 PM
> To: general-toolchain
> Subject: RE: GDB (on PPC target) can't step into functions derived from
> abstract class
>
> Hi Robert,
>
> That's excellent news! I'll do the formal backports to 6.3.2 and to
> 6.4.0.1 and close the PR, if that's OK with you.
>
> Regards,
> Neil
>
> On Thu, 2009-03-12 at 16:38 -0400, Robert D'Attilio wrote:
> > Neil:
> >
> > The patch seems to be working fine now.
> >
> > Many thanks
> > Robert
> >
> > -----Original Message-----
> > From: Neil Schellenberger [mailto:community-noreply@qnx.com]
> > Sent: Wednesday, March 11, 2009 5:28 PM
> > To: general-toolchain
> > Subject: Re: GDB (on PPC target) can't step into functions derived
> from
> > abstract class
> >
> > I've attached patched versions of 6.3.2GA PPC 400 kernels for you to
> > try. These are unofficial, unsupported engineering releases and we
> > would council against using them in a production system.
> >
> >
> > _______________________________________________
> > General
> > http://community.qnx.com/sf/go/post24188
> >
> > _______________________________________________
> > General
> > http://community.qnx.com/sf/go/post24274
> >
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post24275
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post24325
>
|
|
|
|
|
|
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
|
|
03/06/2009 4:35 PM
post23849
|
RE: GDB (on PPC target) can't step into functions derived from abstract class
Colin:
Any idea if the AMCC PPC440 processor is going to have the same issue? I
briefly spoke with their FAE and he said the 440 definitely supports
hardware-breakpoints but I'm not sure that's the same thing as hardware
single-step.
Cheers
Robert
-----Original Message-----
From: Colin Burgess [mailto:community-noreply@qnx.com]
Sent: Monday, March 02, 2009 1:40 PM
To: general-toolchain
Subject: Re: GDB (on PPC target) can't step into functions derived from
abstract class
Hi Robert,
This bug was fixed after the 6.3.2 release. It was a bug in the single
step handling in the kernel.
More specifically it was an error (as you surmised) in the handling of
the bctr* instructions. It worked
for Aleksander because he was testing on a BookE processor, which has
hardware single step, whereas
you are using a 405 processor, which does not, and single step needs to
be emulated by the kernel.
Regards,
Colin
Robert D'Attilio wrote:
> Aleksandar:
>
> Thanks for your help. I tried using an instrumented version of the
> kernel as suggested but I get the same behaviour.
>
> I'll wait to hear back from you when the ppc debug support person
> returns.
>
> Cheers
> Robert
>
>
> -----Original Message-----
> From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
> Sent: Tuesday, February 24, 2009 10:58 AM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived
from
> abstract class
>
> Hello Robert,
>
> Yes, there seems to be a fix that went in after 6.3.2
> release. For more detail, however, we will have to wait for
> the person who works on ppc debug support, who should be
> back in the office next week.
>
> Do you have a workaround for the time being? I can not,
> unfortunately, suggest anything better than setting
> breakpoints explicitly in functions/methods where you want
> to stop.
>
> You may also experiment with different procnto-s (for
> example, even though it is a uniprocessor system, you could
> try procnto-smp or one of the instrumented variants,
> procnto-instr or procnto-smp-instr). It *might* give better
> results. I can not reproduce the problem here, otherwise I
> would have tried that myself.
>
> Thanks,
>
> Aleksandar
>
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post22831
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post22837
>
>
_______________________________________________
General
http://community.qnx.com/sf/go/post23240
|
|
|
|
|
|
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
|
|
03/06/2009 4:39 PM
post23854
|
Re: GDB (on PPC target) can't step into functions derived from abstract
class
The 440 is a booke kernel, I believe, which supports hardware single step.
Robert D'Attilio wrote:
> Colin:
>
> Any idea if the AMCC PPC440 processor is going to have the same issue? I
> briefly spoke with their FAE and he said the 440 definitely supports
> hardware-breakpoints but I'm not sure that's the same thing as hardware
> single-step.
>
> Cheers
> Robert
>
>
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com]
> Sent: Monday, March 02, 2009 1:40 PM
> To: general-toolchain
> Subject: Re: GDB (on PPC target) can't step into functions derived from
> abstract class
>
> Hi Robert,
>
> This bug was fixed after the 6.3.2 release. It was a bug in the single
> step handling in the kernel.
>
> More specifically it was an error (as you surmised) in the handling of
> the bctr* instructions. It worked
> for Aleksander because he was testing on a BookE processor, which has
> hardware single step, whereas
> you are using a 405 processor, which does not, and single step needs to
> be emulated by the kernel.
>
> Regards,
>
> Colin
>
> Robert D'Attilio wrote:
>> Aleksandar:
>>
>> Thanks for your help. I tried using an instrumented version of the
>> kernel as suggested but I get the same behaviour.
>>
>> I'll wait to hear back from you when the ppc debug support person
>> returns.
>>
>> Cheers
>> Robert
>>
>>
>> -----Original Message-----
>> From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
>> Sent: Tuesday, February 24, 2009 10:58 AM
>> To: general-toolchain
>> Subject: Re: GDB (on PPC target) can't step into functions derived
> from
>> abstract class
>>
>> Hello Robert,
>>
>> Yes, there seems to be a fix that went in after 6.3.2
>> release. For more detail, however, we will have to wait for
>> the person who works on ppc debug support, who should be
>> back in the office next week.
>>
>> Do you have a workaround for the time being? I can not,
>> unfortunately, suggest anything better than setting
>> breakpoints explicitly in functions/methods where you want
>> to stop.
>>
>> You may also experiment with different procnto-s (for
>> example, even though it is a uniprocessor system, you could
>> try procnto-smp or one of the instrumented variants,
>> procnto-instr or procnto-smp-instr). It *might* give better
>> results. I can not reproduce the problem here, otherwise I
>> would have tried that myself.
>>
>> Thanks,
>>
>> Aleksandar
>>
>>
>>
>>
>> _______________________________________________
>> General
>> http://community.qnx.com/sf/go/post22831
>>
>>
>> _______________________________________________
>> General
>> http://community.qnx.com/sf/go/post22837
>>
>>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23240
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23849
>
--
cburgess@qnx.com
|
|
|
|
|
|