Re: I'm down to minor quibbles...

[Keith Seitz <kseitz@firetalk.com>]

Grant Edwards wrote:
> 
> The 28-August-2000 snapshot with my recent patches seems to
> work pretty well (well enough to hand over to the applications
> development guys).  I've noticed a couple minor things:
> 
>  1) With the Linux/i586/native target, when I stop execution in
>     a routine for which the source file is unavailable, it
>     displays dissassembled instructions in the source window.
> 
>     The same situation with the RDI target displays "Unable
>     Read Instructions at 0xXXXX" in the source window.
> 
>     This isn't a big deal, but it seems odd.

This probably has something to do with how gdb disassembles memory.
Normally, when not attached to a target, gdb "disassembles" from the
executable. When attached to a target, it usually disassembles directly
from the target's memory. I seem to recall that Insight was changed to
NOT disassemble from the target at all (or only at specific times?). I
wonder if there is some discrepency with the LMA and VMA?

>  2) While the RDI target is executing, the status line
>     continues to display status of "Program stopped at..."
> 
>     It would be nice if the status line changed to "Program
>     running" or something similar.

This typically happens when the target code in gdb does not set
inferior_pid. The actual test to determine if a target is running is in
gdbtk-cmds.c's gdb_target_has_execution. The test checks: inferior_pid
!= 0 && target_has_execution. One of these is not set properly. I
noticed this, too, recently and was going to change it to just check
inferior_pid, exactly the same test that kill_command in inflow.c does.
(Anyone have any comments on this? When I originally wrote
gdb_target_has_execution, I "copied" the test from kill_command. Since
that's changed, I recommend we change it to follow the current
kill_command.)

I'll bet that it works just fine if you take out the "&&
target_has_execution" part of the test.
Keith