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

[Keith Seitz <keiths at redhat dot com>]

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