RE: Problems using Insight/GDB for Coldfire

RE: Problems using Insight/GDB for Coldfire

["Dörr, Dirk"]

Hi!

On Wed, 2003-09-17 at 16:35, Keith Seitz wrote: (@ insight@sources.redhat.com list):

> Ok, I would just whack everything below the "target" command from your
> .gdbinit and save it into another file. You can use the "Command to run
> after attaching to target" thingy in the target selection to source in
> the other script. (So, save everything below the "target" command into,
> e.g., ~/setup-bdm; then open a target selection dialog (File->Target
> Settings...), select the BDM target, fold down the "More Options" thingy
> and type in the "Command to run after attaching" something like "source
> ~/setup-bdm

Executing the init sequence after starting insight improves the situation. 

But there are still problems like losing focus in source, 
register changes are not displayed ...

I get the impression that there is a general problem with bdm and gdb...

I contacted Thomas Elter from embeddedtools.net (they sell the microcross 
gcc based cross-tools) and got this answer:


> [... Snip ...] 
> It appears that the main problem in your development environment is the P&E Micro 
> connection device. It turns out that the P&E Micro connection device, is not compatible with any GNU
> tool suite release from any vendor. The P&E Micro connection device will
> download the object load module to the target, but will not support any
> debug activities with a GNU Debugger like GDB. Microcross made an attempt to
>work with them to find a solution, but they were not interested.

He offers a Abatron BDI2000 and an other BDM interface from Cybertec

Ok. BDI2000 uses tcp/ip remote debugging. But the bdm inteface from cybertec? 
There should be no big difference between this one and the P&E device? 
Both using parallel port.

So my question: 

Is anybody else using the P&E BDM Interface for Coldfire with Insight/gdb
or can confess the compatibility problems of P&E? 



Bye

-- 

Dirk Dörr

Sorry for crossposting! 

Re: [Bdm-devel] RE: Problems using Insight/GDB for Coldfire

[Chris Johns]

Dörr, Dirk wrote:
> 
> I get the impression that there is a general problem with bdm and gdb...
> 

This could be true, and Insight shows the problems. People do use Insight, how-ever I 
do not, so I have to assume it works.

> But the bdm inteface from cybertec? 

The Cybertec pod works with the BDM driver on SF and the BDM driver supports GDB with 
the GDB patch also on SF.

-- 
  Chris Johns, cjohns at cybertec . com . au

Re: [Bdm-devel] RE: Problems using Insight/GDB for Coldfire

[Paul Whitfield]

Dörr, Dirk wrote:

> Hi!
> 
> On Wed, 2003-09-17 at 16:35, Keith Seitz wrote: (@ insight@sources.redhat.com list):
> 
> 
>>Ok, I would just whack everything below the "target" command from your
>>.gdbinit and save it into another file. You can use the "Command to run
>>after attaching to target" thingy in the target selection to source in
>>the other script. (So, save everything below the "target" command into,
>>e.g., ~/setup-bdm; then open a target selection dialog (File->Target
>>Settings...), select the BDM target, fold down the "More Options" thingy
>>and type in the "Command to run after attaching" something like "source
>>~/setup-bdm
> 
> 
> He offers a Abatron BDI2000 and an other BDM interface from Cybertec
> 
> Ok. BDI2000 uses tcp/ip remote debugging. But the bdm inteface from cybertec? 
> There should be no big difference between this one and the P&E device? 
> Both using parallel port.
> 
> So my question: 
> 
> Is anybody else using the P&E BDM Interface for Coldfire with Insight/gdb
> or can confess the compatibility problems of P&E? 
> 

I have used both Cybertec and P&E BDM Interfaces extensively with 
command line gdb without any dramas. As far as I know the P&E is
functional the same as the Cybertec part (at least ours was
until we let one of the ham fisted engineers take it onsite
and kill it!)

I have been attempting to use insight (recent snapshot and bdm patches 
from CVS) on Cygwin. Until recently I could not get a build of insight
and bdm/gdb that would work nicely together on cygwin.

I can get basic functionality to work, i.e. download to ram, breakpoints
after having loaded a .gdbinit file that sets up my hardware correctly.

However, the insight GUI seems to have problems understanding the 
current state of the interface. I.e. the buttons on the top
of the window are always greyed out.

Also I have been having problems with this combo getting watchpoints
to work (this is definitely a bdm/gdb issue).

I hope to spend some more time on this soon, but sadly I am current
doing too many other things to actually get this tested / setup as
well as I would like.

Regards

Paul

Re: [Bdm-devel] RE: Problems using Insight/GDB for Coldfire

[Keith Seitz]

On Wed, 2003-10-01 at 00:20, Paul Whitfield wrote:
> However, the insight GUI seems to have problems understanding the 
> current state of the interface. I.e. the buttons on the top
> of the window are always greyed out.

This is almost always a bug in the backend support for gdb. Do -- all
from the console window:

1) tk ManagedWin::open DebugWin
2) [set baudrate or any other target options]
3) target MYTARGET DEVICE
4) tk gdb_target_has_execution
5) tk set ::gdb_running

Notice that if the backend is operating properly, the answer to both #3
and #4 will be >0. Any errors show up in the debug window?

Keith

Re: [Bdm-devel] RE: Problems using Insight/GDB for Coldfire

[Paul Whitfield]

Keith Seitz wrote:

> On Wed, 2003-10-01 at 00:20, Paul Whitfield wrote:
> 
>>However, the insight GUI seems to have problems understanding the 
>>current state of the interface. I.e. the buttons on the top
>>of the window are always greyed out.
> 
> 
> This is almost always a bug in the backend support for gdb. Do -- all
> from the console window:

One thing... I usually do the target stuff in my .gdbinit file.
Because this is a embedded environment there is a reasonable
amount of setup that needs to be done before it is possible
to communicate with the board (mainly making sure the
memory space is working so there is valid memory to
examine / download into).

Also there procedures vary depending on if I am debugging
code in RAM or in Flash memory, so I have a couple of
diffent init scripts that I run depending on the circumstances.

Is this an issue with Insight?

> 
> 1) tk ManagedWin::open DebugWin
> 2) [set baudrate or any other target options]
> 3) target MYTARGET DEVICE
> 4) tk gdb_target_has_execution
> 5) tk set ::gdb_running
> 

Here is the output from the console window.

gdb) tk ManagedWin::open DebugWin
.debugwin0.debugwin

(gdb) target bdm /dev/bdmcf0
Remote bdm connected to /dev/bdmcf0
  Coldfire debug module version is 1 (5307/5407(e))

(gdb) tk gdb_target_has_execution
0

(gdb) tk set ::gdb_running
0

(gdb)


> Notice that if the backend is operating properly, the answer to both #3
> and #4 will be >0. Any errors show up in the debug window?

As you can see the answers are 0.... no errors in the debug window.

So any pointers to code / documentation for what needs to be
fixed to make the back end work correctly?


Thanks

Paul

Re: [Bdm-devel] RE: Problems using Insight/GDB for Coldfire

[Keith Seitz]

On Thu, 2003-10-02 at 18:20, Paul Whitfield wrote:
> (gdb) target bdm /dev/bdmcf0
> Remote bdm connected to /dev/bdmcf0
>   Coldfire debug module version is 1 (5307/5407(e))
> 
> (gdb) tk gdb_target_has_execution
> 0

This is a problem. This indicates a problem with the target backend.
It's not setting the pid/ptid when the target is attached. See
src/gdb/gdbtk/generic/gdbtk-cmds.c:gdb_target_has_execution_command.

Normally, one of the target vector commands will set ptid (or pid for
older versions of gdb) to non-zero -- typically 42000 or some other
"significant" number.

If you have the source code for the backend, check that something in the
target vector sets the ptid on attach. (See, for example, monitor_open
in monitor.c, which sets "inferior_pid = pid_to_ptid (42000);".

Keith

Re: Problems using Insight/GDB for Coldfire

[Keith Seitz]

On Wed, 2003-09-17 at 01:22, "Dörr, Dirk" wrote:
> I am using the binary version from sourceforge.net.

Can you give me a URI?

> Debugging with gdb works fine:
> 
> > m68k-bdm-elf-gdb tstart.elf
> (gdb) load
> (gdb) set $pc=0x20000
> (gdb)
> list
> (gdb) list
> 1       int _main()
> 2       {
> 3       int i;
> 4       int a=1;
> 5       for (i=0;i<10;i++)
> 6               {
> 7               a*=(i+1);
> 8               }
> 9       for(;;);        return 0;
> 10      }
> (gdb) break 5
> (gdb) c
> Continuing.
> 
> Breakpoint 1, _main () at main.c:5
> 5       for (i=0;i<10;i++)
> 1: x/i $pc  0x20042 <_main+10>: clrl %fp@(-4)
> 
> In the working directory is a .gdbinit file that configures the sdram controller and sets the target to /dev/bdmcf0 .

In the example, I don't see a target command. Please either send (to the
list) the .gdbinit you are using OR run a gdb session IN LINE (i.e,.
"file foo.elf", "target BLAH", "load", "break bar", "continue", ...).

> But with Insight I have the folling problem:
> 
> I start with
> 
> m68k-bdm-elf-insight
> 
> I can see memory and change it. I can see registers but can't change them.

Probably a bug -- you haven't specified a target yet... You shouldn't be
able to change memory or registers.


> Then I choose Run->Download
>
> The download dialog shows: 134 bytes (118 .text and 16 .data). 

Well, it seems that you have attached to a target (probably in
.gdbinit). I'm pretty sure this will confuse Insight enormously,
especially if the target code was written by anyone with no Insight
experience. This issue has come up countless times before.

> But now at 0x20000 there is :
> 
> 0xcebc0000 0xffff2f07 0x48780010 0x61002226
> 
> instead of 
> 
> 0x4e7146fc 0x27002e7c 0x00000000 0x4e7bf801
> 
> and I can't change the memory. 

Well, Insight is just a UI (and a ton of glue code between the
command-line gdb and the Tcl interpreter that runs the UI). The actual
loading is handled by gdb. In fact, with only a few minor differences,
selecting "Run->Download" is EXACTLY the same as typing "load" at the
console.

> What am I doing wrong? 

Again, if I were you, I would NOT put anything in the .gdbinit file
which would alter target state (i.e., no "target" command, no register
setting, no memory altering, etc.). Insight can still read gdb script
files (File->Source...), so if you wanted to do stuff after attaching to
the target, then I would put those things into a script file and source
it in manually.

The problem is that gdb controls when the .gdbinit is read -- it may be
read by gdb before Insight is even initialized. Thus, Insight gets no
notification that anything has happened.

Try running insight WITHOUT the .gdbinit file in place (just rename it
temporarily). Use the following commands to "run" your exe: File->Open,
set a break, click "Run" button (a target selection dialog should show,
allowing you to configure the target). You should not need to anything
more (well, most of the time, at least).

> BTW: The buttons for step, next ... are greyed out.

This is an indication that Insight doesn't know that you've attached to
a target. This could be indicative of a bug in the target code, too, but
we'll diagnose that later. First things first: I need to know a lot more
about your target.

Keith

Problems using Insight/GDB for Coldfire

["Dörr, Dirk"]

[-- Attachment #1: Type: text/plain, Size: 2394 bytes --]

Hi!

I am currently working on a ucLinux project for a MCF5272 and I have some trouble using the Insight/GDB debugger with bdm.

I am using the binary version from sourceforge.net.

Before starting with ucLinux I build a small test application that runs in the SDRAM at 0x20000 (MCF5272C3 eval board).

Debugging with gdb works fine:

> m68k-bdm-elf-gdb tstart.elf
(gdb) load
(gdb) set $pc=0x20000
(gdb)
list
(gdb) list
1       int _main()
2       {
3       int i;
4       int a=1;
5       for (i=0;i<10;i++)
6               {
7               a*=(i+1);
8               }
9       for(;;);        return 0;
10      }
(gdb) break 5
(gdb) c
Continuing.

Breakpoint 1, _main () at main.c:5
5       for (i=0;i<10;i++)
1: x/i $pc  0x20042 <_main+10>: clrl %fp@(-4)

In the working directory is a .gdbinit file that configures the sdram controller and sets the target to /dev/bdmcf0 .

But with Insight I have the folling problem:

I start with

m68k-bdm-elf-insight

I can see memory and change it. I can see registers but can't change them.

File->Open

tstart.elf

Now I can see the code of the application at 0x20000 

but the memory below (0x1fff0)  and above (0x20080) are marked N/A.

Then I choose Run->Download

The download dialog shows: 134 bytes (118 .text and 16 .data). 

m68k-elf-objdump -x tstart.elf:


tstart.elf:     file format elf32-m68k
tstart.elf
architecture: m68k, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x00020000

Program Header:
    LOAD off    0x00002000 vaddr 0x00020000 paddr 0x00020000 align 2**13
         filesz 0x00000088 memsz 0x00000088 flags rwx
private flags = 0:

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000076  00020000  00020000  00002000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000010  00020078  00020078  00002078  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 

Seems ok.

But now at 0x20000 there is :

0xcebc0000 0xffff2f07 0x48780010 0x61002226

instead of 

0x4e7146fc 0x27002e7c 0x00000000 0x4e7bf801

and I can't change the memory. 

What am I doing wrong? 

BTW: The buttons for step, next ... are greyed out.

Thanks
-- 

Dirk Dörr

P. S.:

I posted this message to:

bdm-devel@lists.sourceforge.net
uclinux-dev@uclinux.org

[-- Attachment #2: start.tar.gz --]
[-- Type: application/x-gzip, Size: 5297 bytes --]