gdb problems.

Hi all,

I am currently using GDB to debug some nto stuff but
i have a lot of problems making it work despite the documentation
provided on the QNX site on gdb.

I try to debug on a local node (i.e. no remote connection ).
I have made a simple C application that would allow to test
GDB and its capabilities. I compile it using the common -g
option and it runs well. ( gcc -g main.c -o main )

Then I invoke gdb > “gdb main”.

I check if i am in the right current dir :

“pwd”

I set the path using :

“path .” ( after checking the directory name )

I set a breakpoint using :

“break ma_func”
( gdb answers : Breakpoint 1 at 0x80483d2 : file main.c, line 5 )

I run my program using :

“run”

and … nothing happens except the usual stuff :
“starting program : main
Debug server launched
Launching on pty : /dev/ptyp2”

It should have stopped at the break point ! …
I relaunch it :

“run”

GDB tells me :

"the program being debugged has been started already
Start it from the beginning? (y or n) : "

I answer yes (“y”),

And here is what is printed then :

“Starting program : main
qnx_semi_init
0x0 in ?? ( )”

I have no idea why it does not stop at the previous breakpoint
and what this message means.

I have checked the validity of the breakpoint :

“maintenance info breakpoints”
and my break point is well listed and enabled and the address
seemed to be valid.

I use GDB 4.17 … and NTO 6.0 but the same stuff happens with NTO 6.1.

Here is the ultra simple program that i use for testing purpose ( i don’t
think that
it is be the culprit ):

#include <stdio.h>

void ma_func(int i)
{
int j = i;

j++;

printf(“j = %d\n”, j);

}

int main( int argc, char **argv)
{
int i;

if( argc == 1 ){

i=1;
}

ma_func(i);

return 0;
}


thanks for your helps …


Alexandre Abreu

you should check the gdb doc for “continue” (c) command.
after “run”, type a “c” will give you want you want.

-xtang

Alexandre ABREU <alexandre.abreu@opal-rt.com> wrote:

Hi all,

I am currently using GDB to debug some nto stuff but
i have a lot of problems making it work despite the documentation
provided on the QNX site on gdb.

I try to debug on a local node (i.e. no remote connection ).
I have made a simple C application that would allow to test
GDB and its capabilities. I compile it using the common -g
option and it runs well. ( gcc -g main.c -o main )

Then I invoke gdb > “gdb main”.

I check if i am in the right current dir :

“pwd”

I set the path using :

“path .” ( after checking the directory name )

I set a breakpoint using :

“break ma_func”
( gdb answers : Breakpoint 1 at 0x80483d2 : file main.c, line 5 )

I run my program using :

“run”

and … nothing happens except the usual stuff :
“starting program : main
Debug server launched
Launching on pty : /dev/ptyp2”

It should have stopped at the break point ! …
I relaunch it :

“run”

GDB tells me :

"the program being debugged has been started already
Start it from the beginning? (y or n) : "

I answer yes (“y”),

And here is what is printed then :

“Starting program : main
qnx_semi_init
0x0 in ?? ( )”

I have no idea why it does not stop at the previous breakpoint
and what this message means.

I have checked the validity of the breakpoint :

“maintenance info breakpoints”
and my break point is well listed and enabled and the address
seemed to be valid.

I use GDB 4.17 … and NTO 6.0 but the same stuff happens with NTO 6.1.

Here is the ultra simple program that i use for testing purpose ( i don’t
think that
it is be the culprit ):

#include <stdio.h

void ma_func(int i)
{
int j = i;

j++;

printf(“j = %d\n”, j);

}

int main( int argc, char **argv)
{
int i;

if( argc == 1 ){

i=1;
}

ma_func(i);

return 0;
}



thanks for your helps …


Alexandre Abreu

On most platforms (ie. Linux), when you type ‘run’, gdb just starts running.
On QNX, gdb is compiled such that it starts the program but does not begin
running through it. So if you just type run and then try to step, you’re in
all the startup code that comes before main(). The answer, as Xiodan stated,
is to continue after hitting run. I’m not sure why we do this but I would
guess it’s to make it easier to single step through the startup assembly
code if need be.

cheers,

Kris

Alexandre ABREU <alexandre.abreu@opal-rt.com> wrote:

Hi all,

I am currently using GDB to debug some nto stuff but
i have a lot of problems making it work despite the documentation
provided on the QNX site on gdb.

I try to debug on a local node (i.e. no remote connection ).
I have made a simple C application that would allow to test
GDB and its capabilities. I compile it using the common -g
option and it runs well. ( gcc -g main.c -o main )

Then I invoke gdb > “gdb main”.

I check if i am in the right current dir :

“pwd”

I set the path using :

“path .” ( after checking the directory name )

I set a breakpoint using :

“break ma_func”
( gdb answers : Breakpoint 1 at 0x80483d2 : file main.c, line 5 )

I run my program using :

“run”

and … nothing happens except the usual stuff :
“starting program : main
Debug server launched
Launching on pty : /dev/ptyp2”

It should have stopped at the break point ! …
I relaunch it :

“run”

GDB tells me :

"the program being debugged has been started already
Start it from the beginning? (y or n) : "

I answer yes (“y”),

And here is what is printed then :

“Starting program : main
qnx_semi_init
0x0 in ?? ( )”

I have no idea why it does not stop at the previous breakpoint
and what this message means.

I have checked the validity of the breakpoint :

“maintenance info breakpoints”
and my break point is well listed and enabled and the address
seemed to be valid.

I use GDB 4.17 … and NTO 6.0 but the same stuff happens with NTO 6.1.

Here is the ultra simple program that i use for testing purpose ( i don’t
think that
it is be the culprit ):

#include <stdio.h

void ma_func(int i)
{
int j = i;

j++;

printf(“j = %d\n”, j);

}

int main( int argc, char **argv)
{
int i;

if( argc == 1 ){

i=1;
}

ma_func(i);

return 0;
}



thanks for your helps …


Alexandre Abreu



Kris Warkentin
kewarken@qnx.com
(613)591-0836 x9368
One of the main causes of the fall of the Roman Empire was that, lacking zero,
they had no way to indicate sucessful termination of their C programs.

  • Robert Firth