remote target: single step too slow

remote target: single step too slow

[Ilko Iliev]

Hi,
I found in the last version of gdb next stange effect:
after breakpoint the gdb read the code memory from the beginning of the 
current function in single word mode. This make the single stepping very 
very slow.
Why it is necessary gdb to read code after each breakpoint or single step?
If it is necessary is it not possible to read the code in block mode 
(one packet transaction with remote target)?

My platform:
CPU: ARM7TDMI, arm-elf
Remote target: BDI2000


best regards
ilko iliev

Re: remote target: single step too slow

[Keith Seitz]

On Thu, 2004-11-04 at 06:21, Ilko Iliev wrote:
> I found in the last version of gdb next stange effect:
> after breakpoint the gdb read the code memory from the beginning of the 
> current function in single word mode. This make the single stepping very 
> very slow.
> Why it is necessary gdb to read code after each breakpoint or single step?
> If it is necessary is it not possible to read the code in block mode 
> (one packet transaction with remote target)?

Same with this one: ask on the gdb list for a definitive answer.

Keith

Re: remote target: single step too slow

[Ilko Iliev]

Hi,
I think it is not question for the gdb list.
The command "info locals" in gdb work normally - after breakpoint or
single step gdb reads only the local variables
If the local variables window in insight is open: after each breakpoint
or single step insight reads the local variables and a piece program
code. For example: if there are 10 local variables the insight reads 10
times the same program code.

Is it a feature or a bug?
If it is a future how can I turn it off?

regards
ilko


Keith Seitz wrote:

>On Thu, 2004-11-04 at 06:21, Ilko Iliev wrote:
>  
>
>>I found in the last version of gdb next stange effect:
>>after breakpoint the gdb read the code memory from the beginning of the 
>>current function in single word mode. This make the single stepping very 
>>very slow.
>>Why it is necessary gdb to read code after each breakpoint or single step?
>>If it is necessary is it not possible to read the code in block mode 
>>(one packet transaction with remote target)?
>>    
>>
>
>Same with this one: ask on the gdb list for a definitive answer.
>
>Keith
>  
>

Re: remote target: single step too slow

[Keith Seitz]

On Tue, 2004-11-09 at 01:11, Ilko Iliev wrote:
> I think it is not question for the gdb list.
> The command "info locals" in gdb work normally - after breakpoint or
> single step gdb reads only the local variables
> If the local variables window in insight is open: after each
> breakpoint or single step insight reads the local variables and a
> piece program code. For example: if there are 10 local variables the
> insight reads 10 times the same program code.

You did not mention that you had an open locals window in your last
message... That changes things.

> Is it a feature or a bug?
> If it is a future how can I turn it off?

I believe this is still a gdb problem. The locals window doesn't do
much. It uses gdb's varobj to do all the real work. Here's a quick way
to test: use mi to debug your program. You can test by doing it by hand
(which isn't so tough, but you still need to create all the varobjs by
hand) or via some UI that uses mi, like eclipse.

To run mi by hand, start "gdb --i=mi". You can then do something like:
(gdb)
file gdb
&"file gdb"
(gdb)
-break-insert main
^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x0808f881",func="main",file="../../src/gdb/gdb.c",line="31",times="0"}
(gdb)
-exec-run
^running
(gdb)
*stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x0808f881",func="main",args=[{name="argc",value="0"},{name="argv",value="0x0"}],file="../../src/gdb/gdb.c",line="31"}
(gdb)
info locals
&"info locals\n"
~"args = {"
~"argc = 0, argv = 0x36bffc, "
~"use_windows = 0, "
~"\n"
~"  interpreter_p = 0x36bffc \"\\\\\\2756\"}"
~"\n"
^done
(gdb)
-var-create var1 * args
&"During symbol reading, Incomplete CFI data; unspecified registers at
0x0808f8a2.\n"
^done,name="var1",numchild="4",type="struct captured_main_args"
(gdb)
-var-create var2 * argc
^done,name="var2",numchild="0",type="int"
(gdb)
-var-create var3 * use_windows
^done,name="var3",numchild="0",type="int"
(gdb)
-exec-step
^running
(gdb)
*stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x0808f884",func="main",args=[{name="argc",value="1"},{name="argv",value="0x1"}],file="../../src/gdb/gdb.c",line="30"}
(gdb)
-var-update var1
^done,changelist=[]
(gdb)
-var-update var2
^done,changelist=[{name="var2",in_scope="true",type_changed="false"}]
(gdb)
-var-update var3
^done,changelist=[]
(gdb)

If your problem still occurs (and I bet it does, unless there is
something else you haven't mentioned), it's a problem with varobj and
should go to the gdb list.

Keith

Re: remote target: single step too slow

[Ilko Iliev]

yes, you are right
the problem is in gdb.

regards
ilko


Keith Seitz wrote:

>On Tue, 2004-11-09 at 01:11, Ilko Iliev wrote:
>  
>
>>I think it is not question for the gdb list.
>>The command "info locals" in gdb work normally - after breakpoint or
>>single step gdb reads only the local variables
>>If the local variables window in insight is open: after each
>>breakpoint or single step insight reads the local variables and a
>>piece program code. For example: if there are 10 local variables the
>>insight reads 10 times the same program code.
>>    
>>
>
>You did not mention that you had an open locals window in your last
>message... That changes things.
>
>  
>
>>Is it a feature or a bug?
>>If it is a future how can I turn it off?
>>    
>>
>
>I believe this is still a gdb problem. The locals window doesn't do
>much. It uses gdb's varobj to do all the real work. Here's a quick way
>to test: use mi to debug your program. You can test by doing it by hand
>(which isn't so tough, but you still need to create all the varobjs by
>hand) or via some UI that uses mi, like eclipse.
>
>To run mi by hand, start "gdb --i=mi". You can then do something like:
>(gdb)
>file gdb
>&"file gdb"
>(gdb)
>-break-insert main
>^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x0808f881",func="main",file="../../src/gdb/gdb.c",line="31",times="0"}
>(gdb)
>-exec-run
>^running
>(gdb)
>*stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x0808f881",func="main",args=[{name="argc",value="0"},{name="argv",value="0x0"}],file="../../src/gdb/gdb.c",line="31"}
>(gdb)
>info locals
>&"info locals\n"
>~"args = {"
>~"argc = 0, argv = 0x36bffc, "
>~"use_windows = 0, "
>~"\n"
>~"  interpreter_p = 0x36bffc \"\\\\\\2756\"}"
>~"\n"
>^done
>(gdb)
>-var-create var1 * args
>&"During symbol reading, Incomplete CFI data; unspecified registers at
>0x0808f8a2.\n"
>^done,name="var1",numchild="4",type="struct captured_main_args"
>(gdb)
>-var-create var2 * argc
>^done,name="var2",numchild="0",type="int"
>(gdb)
>-var-create var3 * use_windows
>^done,name="var3",numchild="0",type="int"
>(gdb)
>-exec-step
>^running
>(gdb)
>*stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x0808f884",func="main",args=[{name="argc",value="1"},{name="argv",value="0x1"}],file="../../src/gdb/gdb.c",line="30"}
>(gdb)
>-var-update var1
>^done,changelist=[]
>(gdb)
>-var-update var2
>^done,changelist=[{name="var2",in_scope="true",type_changed="false"}]
>(gdb)
>-var-update var3
>^done,changelist=[]
>(gdb)
>
>If your problem still occurs (and I bet it does, unless there is
>something else you haven't mentioned), it's a problem with varobj and
>should go to the gdb list.
>
>Keith
>  
>