Insight exits abrupt when trying to view in ASM or MIXED mode.

Insight exits abrupt when trying to view in ASM or MIXED mode.

[Paul_Heijman]

Does this sound familiar to anyone:

I am using Insight to remote-debug a 68000 microcontroller.
Almost everything works perfect. After loading the .cof file into GDB, I can
step through the (C) source code.
When I try to view the ASSEMBLY code (in ASSEMBLY or MIXED view mode), Insight
closes without any error message!

I have seen the assembly / mixed mode view working earlier, but then I wasn't
able to view the C source code. I think I solved it by upgrading to a newer
version of cygwin1.dll.

I now have tried several latest versions of the DLL, but it doesn't make a
difference.
Does anyone know of a solution?

Greetings,
Paul Heijmann.

Re: Insight exits abrupt when trying to view in ASM or MIXED mode.

[Keith Seitz]

Paul_Heijman@eu.omron.com wrote:
> 
> Does this sound familiar to anyone:
> 
> I am using Insight to remote-debug a 68000 microcontroller.
> Almost everything works perfect. After loading the .cof file into GDB, I can
> step through the (C) source code.
> When I try to view the ASSEMBLY code (in ASSEMBLY or MIXED view mode), Insight
> closes without any error message!
> 

When you say that you load the ".cof" file, are you loading symbols only
or the executable with symbols? (Are you using Insight's
File->Open/console window's "file" command or using the console command
"add-symbol-file"?)

For the record, let me say (just to warn anyone out there), NEVER use
just the "add-symbol-file" command without ever having used the "file"
command (or File->Open). The problem that ofter arises in Insight
involves disassembling memory. Specifically, Insight does not access
memory on a non-native target the same way that gdb does.

Gdb will always access memory from the executable file UNLESS you're
attached to a target (with the "target" command or its equivalent in
gui-land). When you're attached, gdb will read memory from the actual
target. ALL memory accesses, including disassembly, occur this way.

Insight/gdbtk, on the other hand, will almost always access memory from
the executable on non-native targets. This was added to aid developers
using remote targets with slow communications facilities (like a 9600
baud serial line using a monitor -- yich!).

So, you already state that all disassembly isn't working, so that's a
strong hint that something like this may be happening (gdbtk cannot get
at the memory or something). Can you disassemble BEFORE attaching
(again, ASSEMBLY mode or from console window)?

What version of gdbtk are you using? (Type "show version" in console
window or run "gdb -v".)

Keith
-- 
Why chat when you can Firetalk?
Firetalk ID: Keith (10320)
www.firetalk.com

Re: Insight exits abrupt when trying to view in ASM or MIXED mode.

[Kai Ruottu]

Paul_Heijman@eu.omron.com wrote:
> 
> Does this sound familiar to anyone:
> 
> I am using Insight to remote-debug a 68000 microcontroller.
> Almost everything works perfect. After loading the .cof file into GDB, I can
> step through the (C) source code.
> When I try to view the ASSEMBLY code (in ASSEMBLY or MIXED view mode),
> Insight closes without any error message!
> 
> I have seen the assembly / mixed mode view working earlier, but then I
> wasn't able to view the C source code. I think I solved it by upgrading
> to a newer version of cygwin1.dll.

 This 'feature' isn't related to only Cygwin, also the Linux and Mingw hosts
have had problems (probably all hosts). I found first the 'mips64*' targets
not being able to show the assembly... This is really a '2k'-problem, when
it appeared during December-1999 - January-2000... Later it started to show
with all targets somehow... But normally one sees only that single-stepping
in the 'src+asm' display doesn't update the display... Not as bad as you
have described... BTW, I reported this problem with the 'mips64*' targets
in January-February in this maillist. No response from anyone, so if I'll
find a cure for it, perhaps there is no reason to tell anyone else but you,
when this 'feature' doesn't seem to hurt anyone else but me and you...

 I really will try to fix these problems with the assembly not showing with
the 'mips64*' targets and the single-stepping not updating the display with
any targets... But it may take some time, because I just haven't cared if the
current snapshots work or not, when the older ones do work... But adopting
new things from the new sources to the old working sources has started to
be quite hard...

> I now have tried several latest versions of the DLL, but it doesn't make a
> difference.Does anyone know of a solution?

 I have stayed using the '19991116'-snapshots, (sometimes spying if the
current snapshots have cured the 'features' -- the '20000425' and '20000502'
ones at least weren't...). To get the single-stepping to work, I had to
take still older scripts (19990727) in use...

 BTW, you could try my downloadable 'm68k-elf' and 'm68k-palmos-coff'
Insights for the Mingw host... They are gdb-4.18-based, and if I don't
remember it wrong, someone recently claimed it being impossible to build
gdb-4.18 based Insights, and also the Mingw-host has been doomed as
impossible for a long time... But perhaps I'm too stupid to believe when
the 'wise' men claim these things... Not knowing any better, I even dared
to build ten or more Win3.1x/Win32s-hosted Insights (What a sin this must
be...). Ok, please see ' http://www.saunalahti.fi/~ankosk2/embtools.htm '...

Cheers, Kai

Re: Insight exits abrupt when trying to view in ASM or MIXED mode.

[Keith Seitz]

Paul_Heijman@eu.omron.com wrote:
> 
> >When you say that you load the ".cof" file, are you loading symbols only
> >or the executable with symbols? (Are you using Insight's
> >File->Open/console window's "file" command or using the console command
> >"add-symbol-file"?)
> 
> I load the symbol file from the commandline:
> GDB --baud=38400 -d=//O/Alt/Fwk/new/src -s=//O/Alt/Fwk/new/bin/framewrk.cof
> -readnow
> 
> The .cof file contains code information and also the symbol table.

The file may contain code and symbols, but using "-s=..." will cause gdb
to ONLY read symbols. This is why gdbtk was failing to disassemble
anything.

> The cases that I tried were when connected to the target. When not connected, i
> don't manage to see any code, source nor assembly.

It would make sense that you could not disassemble (and maybe even not
see source). Like I said before, if you are not attached to a remote
target, gdb (and gdbtk) will look at the code you've loaded to do
disassembly. Since you didn't load any code, gdb couldn't show you
anything.

> I can look to the assembly code now, like you said I opened the cof-file
> manually with File->Open.
> After I connected to the target I could see the ASM-source!

Cool! Not bad for my first guess. :-)

> 
> Does this mean it will never work through the commandline ?
> I also didn't provide the source-path in the commandline, so at the moment I
> don't see the C-source.
> 

No, you should be able to invoke gdb/Insight passing the file on the
command line:
$ gdb [args, sans the -s one] myExecutable.cof

In general, the use of "add-symbol-file" and the "-s" command line flag
should be used to read ADDITIONAL symbols into gdb. (Purists will say
that this is not true, and they are correct. However, my experience with
gdb, this advice has never failed.)

Keith
-- 
Why chat when you can Firetalk?
Firetalk ID: Keith (10320)
www.firetalk.com