2:Insight not knowing about execuded gdb.ini commands!

2:Insight not knowing about execuded gdb.ini commands!

[Roman]

Sorry, there are no screenshots allowed in the mails. Therefore the 
first mail is not really understandable. Here a second try.

Hi everyone,

I am programming a NetSilicon ARM7 processor using Microcross Visual
X-Tools 2.2 which include
cygwin 1.2, gcc 2.95.x, Insight/gdbtk 4.18i, OCDLibRemote for
Macraigor-Raven JTAG.

I know that the toolchain is quite old, but for the moment I am bound to it.
Actually these issues are mainly about convenience.

1)
If I start gdbtk without passing the gdb.ini file as command line
argument I will have to click a bunch of button once gdbtk is up
( connecting to the remote server via TCP, loading the gdb.ini file
manually, downloading the programm) to get ready to debug.
If I pass the gdb.ini file as command line argument, I am able to make
gdbtk to connect and download automatically. gdbtk then is ready to debug.
Once I want to restart (run button), gdbtk opens the connect dialog,
probably because the GUI did not recognize that we are connected already.

How can I make gdbtk realize what is executed in the gdb.ini file
(please see the script files at the end of the email)?


2) In the gdb.ini file I change the read write packet sizes in order to
speed up download, which actually works fine, if where was not this
warning window I have to confirm all the time.
I tried several different packet sizes.

Warning window message:
<
This target my not be able to correctly handle a 
memory-write-packet-size of 1024 bytes. Change the packet size?
Yes /No?
 >

Has anyone an idea how get rid of that?

3) The run button in gdbtk does not work, even though I connected
manually to the remote server (not the same problem as 1) ). So I tried
the console within gdbtk
  and typed the run command and got the following result.

Console window:
<
Breakpoint 1, BootSytemUp() at ./../../Global/Bootc:206
(netsilicon-gdb) run
Starting program: 
/cygdrive/d/Daten/MicrocrossARM7/APP_TrxIface/C_Prj/Global/TrxIface32b/image.elf
 >


Warning window message:
<
The program being debugged has been started already. Start it from the
beginning? Yes /No ?
 >

After pressing Yes..

Console window:
<
Error You can't do that without a process to debug.

(netSilicon-gdb)
 >



So how does gdb(tk) know what to run the first time and when I try to
restart it after breaking somewhere in the code it does not?
I assume that the none working RUN-button in the GUI and the error
message in the console have the same cause.

How to fix this?


All the button clicking in issue 1) was not  that bad, if had not to
quit and restart gdbtk everytime I need to start the program debugged
from the beginning.


I would appreciate some hints on that issues. Thanks!!


Regards

Roman



gdb.ini file:
--------------

echo Setting up the environment for debugging gdb.\n

set complaints 1
set output-radix 16
set input-radix 16
set endian big
dir .
set prompt (netsilicon-gdb)

# This connects to a target via netsiliconLibRemote
# listening for commands on this PC's tcp port 8888
#target remote localhost:8888

# Set netSiliconLibRemote to write short/long values
# in big-endian
monitor endian big

# Set GDB in big-endian
set endian big

# Reset the chip to get to a known state.
monitor reset
monitor halt

# NET50 INITIALIZATION VALUES
monitor long 0xffb00000 = 0x4004a000
monitor long 0xffb00000 = 0x4004a000
monitor long 0xffc00000 = 0x0dc00000
monitor long 0xffb00030 = 0x00000000
monitor long 0xffc00034 = 0x00000000
monitor long 0xffc00010 = 0x0
monitor long 0xffc00020 = 0x0

# 16MB RAM
#monitor long 0xffc00024 = 0xf3000070

# 8MB RAM
monitor long 0xffc00024 = 0xf3800070

monitor long 0xffc00020 = 0x0000022d
monitor long 0xffc00028 = 0x00000001
monitor long 0xffc00014 = 0xf3000574
monitor long 0xffc00018 = 0x00000005
monitor long 0xffb00020 = 0xefe00000

# Set Registers to known value
set $r0 = 0
set $r1 = 0
set $r2 = 0
set $r3 = 0
set $r4 = 0
set $r5 = 0
set $r6 = 0
set $r7 = 0
set $r8 = 0
set $r9 = 0
set $r10 = 0
set $r11 = 0
set $r12 = 0
set $sp = 0x80000
set $lr = 0
set $pc = 0
set $cpsr = 0xd3
set $r13 = 0
set $r14 = 0
set $r15 = 0


# Setup GDB FOR FASTER DOWNLOADS
#set remote memory-read-packet-size 1024
#set remote memory-read-packet-size fixed
set remote memory-write-packet-size 1024
set remote memory-write-packet-size fixed

# Load the program executable called "image.elf"
#load image.elf
# Load the symbols for the program.


file: start script with gdb.ini as command line argument
---------------------------------------------------------

#!/bin/bash


bash -c "D:/Daten/MicrocrossARM7/NETOS51_GNU/bin/netSiliconLibRemote.exe &";

bash -c "arm-elf-gdbtk -x 
../../../../HAL_TRXIFACE/dbg/gdb-TrxIface-tk.ini -se image.elf";


file: start script without gdb.ini as command line argument
--------------------------------------------------------------

#!/bin/bash


bash -c "arm-elf-gdbtk -se image.elf &";

bash -c "D:/Daten/MicrocrossARM7/NETOS51_GNU/bin/netSiliconLibRemote.exe";

Re: 2:Insight not knowing about execuded gdb.ini commands!

[Keith Seitz]

On Mon, 2004-05-31 at 05:10, Roman wrote:
> I know that the toolchain is quite old, but for the moment I am bound to it.
> Actually these issues are mainly about convenience.
> 
> 1)
> If I start gdbtk without passing the gdb.ini file as command line
> argument I will have to click a bunch of button once gdbtk is up
> ( connecting to the remote server via TCP, loading the gdb.ini file
> manually, downloading the programm) to get ready to debug.

Why? Just click "Run". It will do everything you've told it to do.

> If I pass the gdb.ini file as command line argument, I am able to make
> gdbtk to connect and download automatically. gdbtk then is ready to debug.
> Once I want to restart (run button), gdbtk opens the connect dialog,
> probably because the GUI did not recognize that we are connected already.

Right -- there are still some disconnects between the GUI and gdb's
internal state. This is one of them. If you use the "run" button,
though, you should be safe.

> How can I make gdbtk realize what is executed in the gdb.ini file
> (please see the script files at the end of the email)?

Ask again after you assess the Run button idea.

> 2) In the gdb.ini file I change the read write packet sizes in order to
> speed up download, which actually works fine, if where was not this
> warning window I have to confirm all the time.
> I tried several different packet sizes.
> 
> Warning window message:
> <
> This target my not be able to correctly handle a 
> memory-write-packet-size of 1024 bytes. Change the packet size?
> Yes /No?
>  >
> Has anyone an idea how get rid of that?

Good question. I don't know where that comes from off the top of my
head, but you could probably add that whole warning to insight's list of
ignorable warnings (which sucks, IMO). Are you already using binary
downloading (if it works with your target, that is)?

Aside from that, I'm not sure what else could be done. Sorry.

> 3) The run button in gdbtk does not work, even though I connected
> manually to the remote server (not the same problem as 1) ). So I tried
> the console within gdbtk
>   and typed the run command and got the following result.
[snip]
> So how does gdb(tk) know what to run the first time and when I try to
> restart it after breaking somewhere in the code it does not?
> I assume that the none working RUN-button in the GUI and the error
> message in the console have the same cause.
> 
> How to fix this?

Ok, let me start at the beginning. The Run button in Insight means "do
whatever it takes to get the target running." There is a list of targets
and run button default behaviors in
src/gdb/gdbtk/library/targetselection.itb. For remote and remote-like
targets, the default run button behavior is:
1) attach to the target (detaching first, if necessary)
2) download ALL code
3) continue the target

The intent was to hide gdb's strict run/continue paradigm for users.
(Gdb people will tell you that one does not "run" a remote target: it
doesn't have processes". They'd be largely correct, too. When using the
console with a remote target, do NOT use "run"; use "continue". The
download will set the PC at the entry point, and your target should be
ready to go.)

The gotcha in all of this, of course, is that the console does NOT know
this layer of abstraction. You are talking to the command-line gdb that
resides within insight. When I use insight, I am very careful to ALWAYS
"run" either entirely via the console OR the run button; never both.

> I would appreciate some hints on that issues. Thanks!!

Let me know (via the list) if you have more questions. (Or should I say,
"when you have more questions"?) :-)

Keith