Byte-order problems with GDB and BDM driver

[Dario Alcocer]

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.

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
    $ 

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
    $ 

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

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

-- 
Dario Alcocer // dalcocer at home.com