This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Load gives inconsistent results


I am using cygwin powerpc-elf-gdb (20000823) with the MPC823 FADS.  I am
using the OCD Wiggler Target to connect (Macraigor Systems OCDemon version
0.21).  Compiler gcc version 2.95.2.

powerpc-elf-gdb -nw -command=gdbinit_823fads.cmd
(gdb) load netd.elf
Loading section .vectors, size 0x1f34 lma 0x0
Loading section .text, size 0x1cc24 lma 0x3000
Loading section .rodata, size 0x1724 lma 0x1fc30
Loading section .sdata2, size 0x4 lma 0x21354
Loading section .data, size 0x3b8 lma 0x21358
Loading section .got2, size 0x18 lma 0x21710
Loading section .sdata, size 0x30 lma 0x21728
Start address 0x100 , load size 132736
Transfer rate: 15849 bits/sec, 502 bytes/write.
(gdb) symbol-file netd.elf
Reading symbols from netd.elf...done.

I can successfully load to the target and debug.  But 60% of the time "load"
seems to fail.  I expect pc to be 0x100 but sometimes it gets reset to
0x8045223d along with all the registers and most of memory.

(gdb)i r
r0             0x8045223d       0x8045223d
r1             0x8045223d       0x8045223d
r2             0x8045223d       0x8045223d
r3             0x8045223d       0x8045223d
r4             0x8045223d       0x8045223d
r5             0x8045223d       0x8045223d
r6             0x8045223d       0x8045223d
r7             0x8045223d       0x8045223d
r8             0x8045223d       0x8045223d
r9             0x8045223d       0x8045223d
r10            0x8045223d       0x8045223d
r11            0x8045223d       0x8045223d
r12            0x8045223d       0x8045223d
r13            0x8045223d       0x8045223d
r14            0x8045223d       0x8045223d
r15            0x8045223d       0x8045223d
r16            0x8045223d       0x8045223d
r17            0x8045223d       0x8045223d
r18            0x8045223d       0x8045223d
r19            0x8045223d       0x8045223d
r20            0x8045223d       0x8045223d
r21            0x8045223d       0x8045223d
r22            0x8045223d       0x8045223d
r23            0x8045223d       0x8045223d
r24            0x8045223d       0x8045223d
r25            0x8045223d       0x8045223d
r26            0x8045223d       0x8045223d
r27            0x8045223d       0x8045223d
r28            0x8045223d       0x8045223d
r29            0x8045223d       0x8045223d
r30            0x8045223d       0x8045223d
r31            0x8045223d       0x8045223d
pc             0x8045223d       0x8045223d
msr            0x8045223d       0x8045223d
cr             0x8045223d       0x8045223d
lr             0x8045223d       0x8045223d
ctr            0x8045223d       0x8045223d
xer            0x8045223d       0x8045223d
dsisr          0x0      0x0
dar            0x8045223d       0x8045223d
dec            0x8045223d       0x8045223d
srr0           0x8045223d       0x8045223d
srr1           0x8045223d       0x8045223d
sprg0          0x8045223d       0x8045223d
sprg1          0x8045223d       0x8045223d
sprg2          0x8045223d       0x8045223d
sprg3          0x8045223d       0x8045223d
pvr            0x8045223d       0x8045223d
dpir           0x8045223d       0x8045223d
immr           0x8045223d       0x8045223d
mi_ctr         0x8045223d       0x8045223d
mi_ap          0x8045223d       0x8045223d
mi_epn         0x8045223d       0x8045223d
mi_twc         0x8045223d       0x8045223d
mi_rpn         0x8045223d       0x8045223d
mi_cam         0x8045223d       0x8045223d
mi_ram0        0x8045223d       0x8045223d
mi_ram1        0x8045223d       0x8045223d
md_ctr         0x8045223d       0x8045223d
m_casid        0x8045223d       0x8045223d
md_ap          0x8045223d       0x8045223d
md_epn         0x8045223d       0x8045223d
md_cam         0x8045223d       0x8045223d
md_ram0        0x8045223d       0x8045223d
md_ram1        0x8045223d       0x8045223d
cmpa           0x8045223d       0x8045223d
cmpb           0x8045223d       0x8045223d
cmpc           0x8045223d       0x8045223d
cmpd           0x8045223d       0x8045223d
icr            0x8045223d       0x8045223d
der            0x8045223d       0x8045223d
counta         0x8045223d       0x8045223d
countb         0x8045223d       0x8045223d
cmpe           0x8045223d       0x8045223d
cmpf           0x8045223d       0x8045223d
cmpg           0x8045223d       0x8045223d
cmph           0x8045223d       0x8045223d
lctrl1         0x8045223d       0x8045223d
lctrl2         0x8045223d       0x8045223d
ictrl          0x8045223d       0x8045223d
bar            0x8045223d       0x8045223d

I have loaded gdb and viewed the registers before doing the "load" and the
registers always appear to be correct.  It is not until the "load" that
things begin to break.

My question is:
What happens during load that could cause this?  The code I am trying to
execute runs perfectly in SingleStep 7.6.2 100% of the time.  This leads me
to believe that I am looking at a bug in gdb.

Thanks in advance.
--------------------------------
Ron Baum
Software Engineer
Email: rbaum@atinucleus.com
--------------------------------


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]