debug plugin

[DoMeN]

Has the debug plugin been changed?
I'm not shore if I understood forum topics about this correctly but is the debug plugin broken at the moment? I've just built latest svn revision and it doesn't work for me anny more and I'm not shore if I made a misstake in settings or what.

Could somebody tell me which was the last svn revision No. before this changes?

Regards,
Domen

[mandrav]

I've just built latest svn revision and it doesn't work for me anny more and I'm not shore if I made a misstake in settings or what.

And if you don't tell us what exactly is not working we won't be able to help...

[DoMeN]

Before I was using rev. 3300 and debugger log was:
[...]
>>>>>>cb_gdb:
> target jtag jtag://10.237.2.35:9999
load
set $pc=0x100
Remote ba debugging using jtag://10.237.2.35:9999
[...some output that jtag returns to gdb...]
>>>>>>cb_gdb:>>>>>>cb_gdb:>>>>>>cb_gdb:
> directory /home/domenv/hello-uart/
>>>>>>cb_gdb:
> delete breakpoints
[...]

Now with rew 3536 it is:
[...]
>>>>>>cb_gdb:
target jtag jtag://10.237.2.35:9999
load
set $pc=0x100
Failed to receive SET_CHAIN response from JTAG proxy: Connection reset by peer
Remote ba debugging using jtag://10.237.2.35:9999
[...nothing...]
>>>>>>cb_gdb:>>>>>>cb_gdb:>>>>>>cb_gdb:
> directory /home/domenv/hello-uart/
You can't do that when your target is `exec'
>>>>>>cb_gdb:
> delete breakpoints
No registers.

[DoMeN]

And all the settings are the same in both revisions.

[mandrav]

Failed to receive SET_CHAIN response from JTAG proxy: Connection reset by peer

What makes you think this is a C::B problem? C::B has nothing to do with JTAG (whatever that is). This is a message returned by the "JTAG proxy".
I 'd like some more help here, if you really think this is a C::B problem.

[DoMeN]

Sory. You were right this was jtag problem that occured after reseting C::B and not the jtag server. But this happened after C::B crashed once.

This is the correct debug log output:

>>>>>>cb_gdb:
> target jtag jtag://10.237.2.35:9999
load
set $pc=0x100
Remote ba debugging using jtag://10.237.2.35:9999
>>>>>>cb_gdb:
> directory /home/domenv/hello-uart/
Loading section .vectors, size 0x124 lma 0x0
Loading section .text, size 0x35c lma 0x2000
Loading section .data, size 0x4 lma 0x235c
Loading section .rodata, size 0x14 lma 0x2360
Start address 0x2000, load size 1176
Transfer rate: 7840 bits/sec, 294 bytes/write.
>>>>>>cb_gdb:>>>>>>cb_gdb:>>>>>>cb_gdb:
> delete breakpoints
>>>>>>cb_gdb:
> break "/home/domenv/hello-uart/hello.c:97"
Breakpoint 1 at 0x22c4: file hello.c, line 97.
>>>>>>cb_gdb:
> break "/home/domenv/hello-uart/hello.c:93"
Breakpoint 2 at 0x2290: file hello.c, line 93.
>>>>>>cb_gdb:
> break "/home/domenv/hello-uart/hello.c:90"
Breakpoint 3 at 0x226c: file hello.c, line 90.
>>>>>>cb_gdb:
> info locals
No symbol table info available.
>>>>>>cb_gdb:
> info args
No symbol table info available.
>>>>>>cb_gdb:
> info frame
Stack level 1, frame at 0xfffb9c:
PC = 0xf000149c; saved PC 0xf000149c
called by frame at 0xfffb9c, caller of frame at 0xfffb9c
Arglist at 0xfffb9c, args:
Locals at 0xfffb9c, Previous frame's sp is 0xfffb9c
>>>>>>cb_gdb:
> disassemble
No function contains program counter for selected frame.
>>>>>>cb_gdb:

And after this I push continue button again and get:
> start
Breakpoint 4 at 0x2264: file hello.c, line 89.

And after this the only option available on debugger is stop debugging and if I push that button C::B crashes.

[DoMeN]

I've built C::B nightly on Debian etch.

Settings for debugger are:
Do not run the debugee
Display debug log
Watch local variables
Watch function arguments

debug initialisation commands:
target jtag jtag://10.237.2.35:9999
load
set $pc=0x100

[DoMeN]

i've checked rev 3300 and before this part wasn't output in log before:

>>>>>>cb_gdb:
> info locals
No symbol table info available.
>>>>>>cb_gdb:
> info args
No symbol table info available.
>>>>>>cb_gdb:
> info frame
Stack level 1, frame at 0xfffb9c:
PC = 0xf000149c; saved PC 0xf000149c
called by frame at 0xfffb9c, caller of frame at 0xfffb9c
Arglist at 0xfffb9c, args:
Locals at 0xfffb9c, Previous frame's sp is 0xfffb9c
>>>>>>cb_gdb:
> disassemble
No function contains program counter for selected frame.

[DoMeN]

I've tested gdb alone so that I've written all the commands that are sent to him in a text file and then coppied them into gdb all at once. I also used the arguments that C::B sends to gdb on start up. Everything works fine so there must be a problem with C::B.

mandrav could you please tell me what else besides sending commands to and reciving them from gdb does this plugin do?
Also could you please tell me why there are all those >>>>>> and cb_gdb: writen to debugger log?
I would also need to know which function is responsible for sending and which for reciving gdb commands.

r. Domen

[mandrav]

mandrav could you please tell me what else besides sending commands to and reciving them from gdb does this plugin do?

Nothing. That is exactly what it does (and interfaces with the gui, of course).

Also could you please tell me why there are all those >>>>>> and cb_gdb: writen to debugger log?

This is the gdb prompt, as set by the plugin.

I would also need to know which function is responsible for sending and which for reciving gdb commands.

This is kind of complex and requires studying the plugin code. It's in src/plugins/debuggergdb/*

[DoMeN]

I've found one of the problems and submited the patch to berilOS: 001855. But there seems to be more problems. Could someone confirm that this setting works for all gdbs on linux not just mine which is patched.

Code Select Expand


--- src/plugins/debuggergdb/gdb_driver.cpp      2007-01-25 16:11:54.000000000 +0100
+++ src/plugins/debuggergdb/gdb_driver.cpp      2007-01-25 16:15:38.000000000 +0100
@@ -375,7 +375,7 @@
     }
#else
     m_BreakOnEntry = breakOnEntry;
-    m_ManualBreakOnEntry = true;
+    m_ManualBreakOnEntry = false;

     if (!Manager::Get()->GetConfigManager(_T("debugger"))->ReadBool(_T("do_not_run"), false))
     {


[DoMeN]

The reason why I havent noticed this before is that before #if (defined( __LINUX__) || defined(__WXMAC__)) was used instead of #if (defined( __WXMSW__) || defined(__WXMAC__)) so this part of the code wasnt even compiled as I am using LInux.

[DoMeN]

I've found the second problem and it was in my gdb. It didn't execute run command propperly. Now it works 

r. Domen