Byte-order problems with GDB and BDM driver

Wed Jun 21 12:43:25 UTC 2000

Dario Alcocer wrote:
> 
> I've got more information regarding the byte-ordering problem using
> the BDM interface with gdb.  As per Chris John's suggestion, I
> downloaded gdb-5.0 and patched it using the latest BDM patch.  I still
> get the byte-ordering problems.
> 
> However, it now appears that there's something *definitely* wrong with
> how bdmReadMemory() works, at least with my Coldfire setup using the
> P&E Coldfire pod.
> 

I think you are correct, something is wrong. I am currently not sure
what it is.

>
> First, here's a run that exhibits the problem:
> 
>     $ /opt/rtems/gdb/bin/m68k-bdm-elf-gdb hello.exe
>     GNU gdb 5.0
>     Copyright 2000 Free Software Foundation, Inc.
>     GDB is free software, covered by the GNU General Public License, and you are
>     welcome to change it and/or distribute copies of it under certain conditions.
>     Type "show copying" to see the conditions.
>     There is absolutely no warranty for GDB.  Type "show warranty" for
>     details.
>     This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-bdm-elf"...
>     (gdb) load
>     (gdb) bdm_setdebug 1
>     (gdb) x/16bx 0x20000
>     BDM: Read 00 @  0x20000
>     BDM: Read 00 @  0x20001
>     BDM: Read 00 @  0x20002
>     BDM: Read 00 @  0x20003
>     BDM: Read 00 @  0x20004
>     BDM: Read 0x7c @  0x20005
>     BDM: Read 00 @  0x20006
>     BDM: Read 0x03 @  0x20007
>     0x20000:    0x00    0x00    0x00    0x00    0x00    0x7c    0x00
>     0x03
>     BDM: Read 0x2e @  0x20008
>     BDM: Read 0x30 @  0x20009
>     BDM: Read 0x4e @  0x2000a
>     BDM: Read 0xf9 @  0x2000b
>     BDM: Read 0x34 @  0x2000c
>     BDM: Read 0x02 @  0x2000d
>     BDM: Read 0x0c @  0x2000e
>     BDM: Read 0x70 @  0x2000f
>     0x20008 <start+4>:  0x2e    0x30    0x4e    0xf9    0x34    0x02
>     0x0c
>     0x70
>     (gdb) q
>     BDM: Status 0x2
>     $
> 

On a 5206e and a P&E pod I get :

$ m68k-bdm-elf-gdb sfp.elf
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=m68k-bdm-elf"...
(gdb) bdm_setdebug 1
(gdb) x/16bx 0x20000
BDM: Read 0x26 @  0x20000
BDM: Read 0x2e @  0x20001
BDM: Read 00 @  0x20002
BDM: Read 0x08 @  0x20003
BDM: Read 0x24 @  0x20004
BDM: Read 0x2e @  0x20005
BDM: Read 00 @  0x20006
BDM: Read 0x0c @  0x20007
0x20000:        0x26    0x2e    0x00    0x08    0x24    0x2e    0x00   
0x0c
BDM: Read 0x4a @  0x20008
BDM: Read 0xb9 @  0x20009
BDM: Read 00 @  0x2000a
BDM: Read 0x14 @  0x2000b
BDM: Read 0xb8 @  0x2000c
BDM: Read 00 @  0x2000d
BDM: Read 0x66 @  0x2000e
BDM: Read 0x10 @  0x2000f
0x20008:        0x4a    0xb9    0x00    0x14    0xb8    0x00    0x66   
0x10
(gdb) q
BDM: Status 0x4
BDM: Go

>
> The bytes above are *incorrect*; the correct byte sequence is:
> 
>     20000:       0000 0000
>     20004:       2e7c 0003
>     20008:       3430 4ef9
>     2000c:       0002 0c70
> 
> However, if I perform a short read *before* I attempt the byte read, I
> get the correct result:
> 
>     $ /opt/rtems/gdb/bin/m68k-bdm-elf-gdb hello.exe
>     GNU gdb 5.0
>     Copyright 2000 Free Software Foundation, Inc.
>     GDB is free software, covered by the GNU General Public License, and you are
>     welcome to change it and/or distribute copies of it under certain conditions.
>     Type "show copying" to see the conditions.
>     There is absolutely no warranty for GDB.  Type "show warranty" for
>     details.
>     This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-bdm-elf"...
>     (gdb) load
>     (gdb) bdm_setdebug 1
>     (gdb) x/4hx 0x20000
>     BDM: Read 0000 @  0x20000
>     BDM: Read 0000 @  0x20002
>     BDM: Read 0x2e7c @  0x20004
>     BDM: Read 0x0003 @  0x20006
>     0x20000:    0x0000  0x0000  0x2e7c  0x0003
>     (gdb) x/8bx 0x20000
>     BDM: Read 00 @  0x20000
>     BDM: Read 00 @  0x20001
>     BDM: Read 00 @  0x20002
>     BDM: Read 00 @  0x20003
>     BDM: Read 0x2e @  0x20004
>     BDM: Read 0x7c @  0x20005
>     BDM: Read 00 @  0x20006
>     BDM: Read 0x03 @  0x20007
>     0x20000:    0x00    0x00    0x00    0x00    0x2e    0x7c    0x00
>     0x03
>     (gdb) q
>     BDM: Status 0
>     $
> 

$ m68k-bdm-elf-gdb sfp.elf
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=m68k-bdm-elf"...
(gdb) bdm_setdebug 1
(gdb) x/4hx 0x20000
BDM: Read 0x262e @  0x20000
BDM: Read 0x0008 @  0x20002
BDM: Read 0x242e @  0x20004
BDM: Read 0x000c @  0x20006
0x20000:        0x262e  0x0008  0x242e  0x000c
(gdb) x/8bx 0x20000
BDM: Read 0x26 @  0x20000
BDM: Read 0x2e @  0x20001
BDM: Read 00 @  0x20002
BDM: Read 0x08 @  0x20003
BDM: Read 0x24 @  0x20004
BDM: Read 0x2e @  0x20005
BDM: Read 00 @  0x20006
BDM: Read 0x0c @  0x20007
0x20000:        0x26    0x2e    0x00    0x08    0x24    0x2e    0x00   
0x0c
(gdb) q
BDM: Status 0x4
BDM: Go 

>
> Notice how both the short and byte reads yield the correct results.
> 

Yes. I will need to look at this more. I will try and modify the `chk'
program to try and generate the problem.

>
> Any ideas why the order of short and byte reads would be significant?
> 

I will try the same target 5307 target as you tomorrow and see what get.

-- 
 Chris Johns, mailto:cjohns at cybertec.com.au mailto:ccj at acm.org