* mipsbe solib event breakpoint endian? @ 2003-07-03 14:59 Kris Warkentin [not found] ` <1030708201312.ZM4704@localhost.localdomain> 0 siblings, 1 reply; 9+ messages in thread From: Kris Warkentin @ 2003-07-03 14:59 UTC (permalink / raw) To: Gdb@Sources.Redhat.Com I'm having a problem with debugging on a mips big endian target. Mipsle works fine but on mipsbe it looks like the solib-event breakpoint is cross-endian. I don't have a target available right at this moment to show you the exact output but it's trying to set the breakpoint at some freaking huge number that doesn't look right at all. I'm assuming that it's reading the memory from the target but not flipping it for some reason. Now obviously this works for PowerPC so the functionality must be there. Can anyone tell me if I'm barking up the wrong tree? cheers, Kris ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <1030708201312.ZM4704@localhost.localdomain>]
* Re: mipsbe solib event breakpoint endian? [not found] ` <1030708201312.ZM4704@localhost.localdomain> @ 2003-07-10 15:05 ` Kris Warkentin 2003-07-10 15:09 ` Daniel Jacobowitz 2003-07-10 15:15 ` Kevin Buettner 0 siblings, 2 replies; 9+ messages in thread From: Kris Warkentin @ 2003-07-10 15:05 UTC (permalink / raw) To: Kevin Buettner; +Cc: Gdb@Sources.Redhat.Com Finally got around to chasing this again and I've found the problem. I'm hoping someone might be able to explain why I'm seeing what I'm seeing. GDB-5.2.1 targetting QNX MipsBE: Breakpoint 4, enable_break () at ../../gdb/solib-svr4.c:939 939 if (!load_addr_found) (top) n 940 load_addr = read_pc () - tmp_bfd->start_address; (top) p read_pc() $1 = 1882417036 (top) p /x read_pc() $2 = 0x7033678c (top) GDB-HEAD targetting QNX MipsBE: Breakpoint 3, enable_break () at ../../gdb/solib-svr4.c:1039 1039 load_addr = read_pc () - tmp_bfd->start_address; (top) p read_pc() $1 = 8084919611063009279 (top) p /x read_pc() $2 = 0x7033678ceeffffff (top) Looks like someone thinks the program counter is a 64 bit value.... Any hints? cheers, Kris > On Jul 3, 11:00am, Kris Warkentin wrote: > > > I'm having a problem with debugging on a mips big endian target. Mipsle > > works fine but on mipsbe it looks like the solib-event breakpoint is > > cross-endian. I don't have a target available right at this moment to show > > you the exact output but it's trying to set the breakpoint at some freaking > > huge number that doesn't look right at all. I'm assuming that it's reading > > the memory from the target but not flipping it for some reason. Now > > obviously this works for PowerPC so the functionality must be there. > > > > Can anyone tell me if I'm barking up the wrong tree? > > I've done some work on MIPS recently and do not recall seeing this > kind of problem. > > Kevin > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mipsbe solib event breakpoint endian? 2003-07-10 15:05 ` Kris Warkentin @ 2003-07-10 15:09 ` Daniel Jacobowitz 2003-07-10 15:15 ` Kevin Buettner 1 sibling, 0 replies; 9+ messages in thread From: Daniel Jacobowitz @ 2003-07-10 15:09 UTC (permalink / raw) To: Kris Warkentin; +Cc: Kevin Buettner, Gdb@Sources.Redhat.Com On Thu, Jul 10, 2003 at 11:06:01AM -0400, Kris Warkentin wrote: > Finally got around to chasing this again and I've found the problem. I'm > hoping someone might be able to explain why I'm seeing what I'm seeing. > > GDB-5.2.1 targetting QNX MipsBE: > Breakpoint 4, enable_break () at ../../gdb/solib-svr4.c:939 > 939 if (!load_addr_found) > (top) n > 940 load_addr = read_pc () - tmp_bfd->start_address; > (top) p read_pc() > $1 = 1882417036 > (top) p /x read_pc() > $2 = 0x7033678c > (top) > > > GDB-HEAD targetting QNX MipsBE: > Breakpoint 3, enable_break () at ../../gdb/solib-svr4.c:1039 > 1039 load_addr = read_pc () - tmp_bfd->start_address; > (top) p read_pc() > $1 = 8084919611063009279 > (top) p /x read_pc() > $2 = 0x7033678ceeffffff > (top) > > Looks like someone thinks the program counter is a 64 bit value.... Any > hints? The CORE_ADDR type _is_ a 64-bit value, and MIPS addresses do sign extend; this has caused all sorts of interesting problems, if you check the list archives. Something has read it in endian-swapped, however. I'd investigate what; maybe REGISTER_BYTE fallout? I haven't seen this happen on my MIPS targets either. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mipsbe solib event breakpoint endian? 2003-07-10 15:05 ` Kris Warkentin 2003-07-10 15:09 ` Daniel Jacobowitz @ 2003-07-10 15:15 ` Kevin Buettner 2003-07-10 15:33 ` Kris Warkentin 1 sibling, 1 reply; 9+ messages in thread From: Kevin Buettner @ 2003-07-10 15:15 UTC (permalink / raw) To: Kris Warkentin, Kevin Buettner; +Cc: Gdb@Sources.Redhat.Com On Jul 10, 11:06am, Kris Warkentin wrote: > Finally got around to chasing this again and I've found the problem. I'm > hoping someone might be able to explain why I'm seeing what I'm seeing. > > GDB-5.2.1 targetting QNX MipsBE: > Breakpoint 4, enable_break () at ../../gdb/solib-svr4.c:939 > 939 if (!load_addr_found) > (top) n > 940 load_addr = read_pc () - tmp_bfd->start_address; > (top) p read_pc() > $1 = 1882417036 > (top) p /x read_pc() > $2 = 0x7033678c > (top) > > > GDB-HEAD targetting QNX MipsBE: > Breakpoint 3, enable_break () at ../../gdb/solib-svr4.c:1039 > 1039 load_addr = read_pc () - tmp_bfd->start_address; > (top) p read_pc() > $1 = 8084919611063009279 > (top) p /x read_pc() > $2 = 0x7033678ceeffffff > (top) > > Looks like someone thinks the program counter is a 64 bit value.... Any > hints? Do "maint print arch" in both to see what's changed. Kevin ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mipsbe solib event breakpoint endian? 2003-07-10 15:15 ` Kevin Buettner @ 2003-07-10 15:33 ` Kris Warkentin 2003-07-10 17:05 ` Andrew Cagney 0 siblings, 1 reply; 9+ messages in thread From: Kris Warkentin @ 2003-07-10 15:33 UTC (permalink / raw) To: Kevin Buettner; +Cc: Gdb@Sources.Redhat.Com > On Jul 10, 11:06am, Kris Warkentin wrote: > > > Finally got around to chasing this again and I've found the problem. I'm > > hoping someone might be able to explain why I'm seeing what I'm seeing. > > > > GDB-5.2.1 targetting QNX MipsBE: > > Breakpoint 4, enable_break () at ../../gdb/solib-svr4.c:939 > > 939 if (!load_addr_found) > > (top) n > > 940 load_addr = read_pc () - tmp_bfd->start_address; > > (top) p read_pc() > > $1 = 1882417036 > > (top) p /x read_pc() > > $2 = 0x7033678c > > (top) > > > > > > GDB-HEAD targetting QNX MipsBE: > > Breakpoint 3, enable_break () at ../../gdb/solib-svr4.c:1039 > > 1039 load_addr = read_pc () - tmp_bfd->start_address; > > (top) p read_pc() > > $1 = 8084919611063009279 > > (top) p /x read_pc() > > $2 = 0x7033678ceeffffff > > (top) > > > > Looks like someone thinks the program counter is a 64 bit value.... Any > > hints? > > Do "maint print arch" in both to see what's changed. Would you believe that they're exactly the same? I ran maint print arch on both, copied to text files and diffed them. No differences. That sounds almost impossible doesn't it? I had to do it twice before I believed it. cheers, Kris ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mipsbe solib event breakpoint endian? 2003-07-10 15:33 ` Kris Warkentin @ 2003-07-10 17:05 ` Andrew Cagney 2003-07-10 17:16 ` Kris Warkentin 0 siblings, 1 reply; 9+ messages in thread From: Andrew Cagney @ 2003-07-10 17:05 UTC (permalink / raw) To: Kris Warkentin; +Cc: Kevin Buettner, Gdb@Sources.Redhat.Com > Looks like someone thinks the program counter is a 64 bit value.... Any >> > hints? > >> >> Do "maint print arch" in both to see what's changed. > > > Would you believe that they're exactly the same? I ran maint print arch on > both, copied to text files and diffed them. No differences. That sounds > almost impossible doesn't it? I had to do it twice before I believed it. > > cheers, Try `maint print {raw-,}registers' and `set debug target 1'. DanielJ's hunch about swapping the low/high words looks right. The existing MIPS code does evil stuff related to register raw size. It current stores 32 bit register values in the lower half of a 64 bit raw register, rather than the least significant half. But only sometimes and not consistently :-( Andrew ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mipsbe solib event breakpoint endian? 2003-07-10 17:05 ` Andrew Cagney @ 2003-07-10 17:16 ` Kris Warkentin 2003-07-10 18:42 ` Andrew Cagney 0 siblings, 1 reply; 9+ messages in thread From: Kris Warkentin @ 2003-07-10 17:16 UTC (permalink / raw) To: Andrew Cagney; +Cc: Kevin Buettner, Gdb@Sources.Redhat.Com > Try `maint print {raw-,}registers' and `set debug target 1'. DanielJ's > hunch about swapping the low/high words looks right. I don't see any maint print registers commands....all I see are: architecture msymbols objfiles psymbols statistics symbols type ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mipsbe solib event breakpoint endian? 2003-07-10 17:16 ` Kris Warkentin @ 2003-07-10 18:42 ` Andrew Cagney 2003-07-10 19:14 ` Kris Warkentin 0 siblings, 1 reply; 9+ messages in thread From: Andrew Cagney @ 2003-07-10 18:42 UTC (permalink / raw) To: Kris Warkentin; +Cc: Kevin Buettner, Gdb@Sources.Redhat.Com > Try `maint print {raw-,}registers' and `set debug target 1'. DanielJ's >> hunch about swapping the low/high words looks right. > > > I don't see any maint print registers commands....all I see are: > > architecture msymbols objfiles psymbols statistics > symbols type That GDB is too old. You're missing both maint print registers and maint print reggroups :-( ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mipsbe solib event breakpoint endian? 2003-07-10 18:42 ` Andrew Cagney @ 2003-07-10 19:14 ` Kris Warkentin 0 siblings, 0 replies; 9+ messages in thread From: Kris Warkentin @ 2003-07-10 19:14 UTC (permalink / raw) To: Andrew Cagney; +Cc: Kevin Buettner, Gdb@Sources.Redhat.Com Oops...I just realized that I was doing the maint print in the (top) gdb rather than the target. The head branch has those commands although my 5.2.1 doesn't. (gdb) maint print registers Name Nr Rel Offset Size Type '' 0 0 0 8 long long '' 1 1 8 8 long long '' 2 2 16 8 long long '' 3 3 24 8 long long '' 4 4 32 8 long long '' 5 5 40 8 long long '' 6 6 48 8 long long '' 7 7 56 8 long long '' 8 8 64 8 long long '' 9 9 72 8 long long '' 10 10 80 8 long long '' 11 11 88 8 long long '' 12 12 96 8 long long '' 13 13 104 8 long long '' 14 14 112 8 long long '' 15 15 120 8 long long '' 16 16 128 8 long long '' 17 17 136 8 long long '' 18 18 144 8 long long '' 19 19 152 8 long long '' 20 20 160 8 long long '' 21 21 168 8 long long '' 22 22 176 8 long long '' 23 23 184 8 long long '' 24 24 192 8 long long '' 25 25 200 8 long long '' 26 26 208 8 long long '' 27 27 216 8 long long '' 28 28 224 8 long long '' 29 29 232 8 long long '' 30 30 240 8 long long '' 31 31 248 8 long long '' 32 32 256 4*1 uint32_t '' 33 33 260 8 long long '' 34 34 268 8 long long '' 35 35 276 8 long long '' 36 36 284 8 long long '' 37 37 292 8 long long '' 38 38 300 8 double '' 39 39 308 8 double '' 40 40 316 8 double '' 41 41 324 8 double '' 42 42 332 8 double '' 43 43 340 8 double '' 44 44 348 8 double '' 45 45 356 8 double '' 46 46 364 8 double '' 47 47 372 8 double '' 48 48 380 8 double '' 49 49 388 8 double '' 50 50 396 8 double '' 51 51 404 8 double '' 52 52 412 8 double '' 53 53 420 8 double '' 54 54 428 8 double '' 55 55 436 8 double '' 56 56 444 8 double '' 57 57 452 8 double '' 58 58 460 8 double '' 59 59 468 8 double '' 60 60 476 8 double '' 61 61 484 8 double '' 62 62 492 8 double '' 63 63 500 8 double '' 64 64 508 8 double '' 65 65 516 8 double '' 66 66 524 8 double '' 67 67 532 8 double '' 68 68 540 8 double '' 69 69 548 8 double '' 70 70 556 4*1 uint32_t '' 71 71 560 4*1 uint32_t '' 72 72 564 4*1 uint32_t '' 73 73 568 4*1 uint32_t '' 74 74 572 4*1 uint32_t '' 75 75 576 4*1 uint32_t '' 76 76 580 4*1 uint32_t '' 77 77 584 4*1 uint32_t '' 78 78 588 4*1 uint32_t '' 79 79 592 4*1 uint32_t '' 80 80 596 4*1 uint32_t '' 81 81 600 4*1 uint32_t '' 82 82 604 4*1 uint32_t '' 83 83 608 4*1 uint32_t '' 84 84 612 4*1 uint32_t '' 85 85 616 4*1 uint32_t '' 86 86 620 4*1 uint32_t '' 87 87 624 4*1 uint32_t '' 88 88 628 4*1 uint32_t '' 89 89 632 4*1 uint32_t zero 90 0 636 8 long long at 91 1 644 8 long long v0 92 2 652 8 long long v1 93 3 660 8 long long a0 94 4 668 8 long long a1 95 5 676 8 long long a2 96 6 684 8 long long a3 97 7 692 8 long long t0 98 8 700 8 long long t1 99 9 708 8 long long t2 100 10 716 8 long long t3 101 11 724 8 long long t4 102 12 732 8 long long t5 103 13 740 8 long long t6 104 14 748 8 long long t7 105 15 756 8 long long s0 106 16 764 8 long long s1 107 17 772 8 long long s2 108 18 780 8 long long s3 109 19 788 8 long long s4 110 20 796 8 long long s5 111 21 804 8 long long s6 112 22 812 8 long long s7 113 23 820 8 long long t8 114 24 828 8 long long t9 115 25 836 8 long long k0 116 26 844 8 long long k1 117 27 852 8 long long gp 118 28 860 8 long long sp 119 29 868 8 long long s8 120 30 876 8 long long ra 121 31 884 8 long long sr 122 32 892 4 uint32_t lo 123 33 896 8 long long hi 124 34 904 8 long long bad 125 35 912 8 long long cause 126 36 920 8 long long pc 127 37 928 8 long long f0 128 38 936 8 double f1 129 39 944 8 double f2 130 40 952 8 double f3 131 41 960 8 double f4 132 42 968 8 double f5 133 43 976 8 double f6 134 44 984 8 double f7 135 45 992 8 double f8 136 46 1000 8 double f9 137 47 1008 8 double f10 138 48 1016 8 double f11 139 49 1024 8 double f12 140 50 1032 8 double f13 141 51 1040 8 double f14 142 52 1048 8 double f15 143 53 1056 8 double f16 144 54 1064 8 double f17 145 55 1072 8 double f18 146 56 1080 8 double f19 147 57 1088 8 double f20 148 58 1096 8 double f21 149 59 1104 8 double f22 150 60 1112 8 double f23 151 61 1120 8 double f24 152 62 1128 8 double f25 153 63 1136 8 double f26 154 64 1144 8 double f27 155 65 1152 8 double f28 156 66 1160 8 double f29 157 67 1168 8 double f30 158 68 1176 8 double f31 159 69 1184 8 double fsr 160 70 1192 4 uint32_t fir 161 71 1196 4 uint32_t '' 162 72 1200 4 uint32_t '' 163 73 1204 4 uint32_t '' 164 74 1208 4 uint32_t '' 165 75 1212 4 uint32_t '' 166 76 1216 4 uint32_t '' 167 77 1220 4 uint32_t '' 168 78 1224 4 uint32_t '' 169 79 1228 4 uint32_t '' 170 80 1232 4 uint32_t '' 171 81 1236 4 uint32_t '' 172 82 1240 4 uint32_t '' 173 83 1244 4 uint32_t '' 174 84 1248 4 uint32_t '' 175 85 1252 4 uint32_t '' 176 86 1256 4 uint32_t '' 177 87 1260 4 uint32_t '' 178 88 1264 4 uint32_t '' 179 89 1268 4 uint32_t *1: Inconsistent register sizes. (gdb) (gdb) maint print raw-registers Name Nr Rel Offset Size Type Raw value '' 0 0 0 8 long long 0x00000000ffffffff '' 1 1 8 8 long long 0x8008000000000000 '' 2 2 16 8 long long 0x0000000000000000 '' 3 3 24 8 long long 0x0000000300000000 '' 4 4 32 8 long long 0x40000000ffffffff '' 5 5 40 8 long long 0x8002000800000000 '' 6 6 48 8 long long 0x0000000100000000 '' 7 7 56 8 long long 0x0000000000000000 '' 8 8 64 8 long long 0x0000000000000000 '' 9 9 72 8 long long 0x0002100000000000 '' 10 10 80 8 long long 0x0000000000000000 '' 11 11 88 8 long long 0x000000010000002f '' 12 12 96 8 long long 0x08018fae00000000 '' 13 13 104 8 long long 0x000000000000002d '' 14 14 112 8 long long 0x000008010000002e '' 15 15 120 8 long long 0x0000000500000000 '' 16 16 128 8 long long 0x00000000ffffffff '' 17 17 136 8 long long 0x8002000000000000 '' 18 18 144 8 long long 0x00000000ffffffff '' 19 19 152 8 long long 0x8002286000000000 '' 20 20 160 8 long long 0x0000000000000000 '' 21 21 168 8 long long 0x0000000000000000 '' 22 22 176 8 long long 0x0000000000000000 '' 23 23 184 8 long long 0x0000000000000000 '' 24 24 192 8 long long 0x00000000ffffffff '' 25 25 200 8 long long 0x8004450400000000 '' 26 26 208 8 long long 0x0000000000000000 '' 27 27 216 8 long long 0x00000000ffffffff '' 28 28 224 8 long long 0x8008434000000000 '' 29 29 232 8 long long 0x08018e7000000000 '' 30 30 240 8 long long 0x0000000000000000 '' 31 31 248 8 long long 0x0000000000000000 '' 32 32 256 4*1 uint32_t 0x0000047300000000 '' 33 33 260 8 long long 0x0000000800000000 '' 34 34 268 8 long long 0x0000000000000000 '' 35 35 276 8 long long 0x703678fc00000000 '' 36 36 284 8 long long 0x0000000000000000 '' 37 37 292 8 long long 0x7033678c89ffffff '' 38 38 300 8 double <invalid> '' 39 39 308 8 double <invalid> '' 40 40 316 8 double <invalid> '' 41 41 324 8 double <invalid> '' 42 42 332 8 double <invalid> '' 43 43 340 8 double <invalid> '' 44 44 348 8 double <invalid> '' 45 45 356 8 double <invalid> '' 46 46 364 8 double <invalid> '' 47 47 372 8 double <invalid> '' 48 48 380 8 double <invalid> '' 49 49 388 8 double <invalid> '' 50 50 396 8 double <invalid> '' 51 51 404 8 double <invalid> '' 52 52 412 8 double <invalid> '' 53 53 420 8 double <invalid> '' 54 54 428 8 double <invalid> '' 55 55 436 8 double <invalid> '' 56 56 444 8 double <invalid> '' 57 57 452 8 double <invalid> '' 58 58 460 8 double <invalid> '' 59 59 468 8 double <invalid> '' 60 60 476 8 double <invalid> '' 61 61 484 8 double <invalid> '' 62 62 492 8 double <invalid> '' 63 63 500 8 double <invalid> '' 64 64 508 8 double <invalid> '' 65 65 516 8 double <invalid> '' 66 66 524 8 double <invalid> '' 67 67 532 8 double <invalid> '' 68 68 540 8 double <invalid> '' 69 69 548 8 double <invalid> '' 70 70 556 4*1 uint32_t <invalid> '' 71 71 560 4*1 uint32_t <invalid> '' 72 72 564 4*1 uint32_t <invalid> '' 73 73 568 4*1 uint32_t <invalid> '' 74 74 572 4*1 uint32_t <invalid> '' 75 75 576 4*1 uint32_t <invalid> '' 76 76 580 4*1 uint32_t <invalid> '' 77 77 584 4*1 uint32_t <invalid> '' 78 78 588 4*1 uint32_t <invalid> '' 79 79 592 4*1 uint32_t <invalid> '' 80 80 596 4*1 uint32_t <invalid> '' 81 81 600 4*1 uint32_t <invalid> '' 82 82 604 4*1 uint32_t <invalid> '' 83 83 608 4*1 uint32_t <invalid> '' 84 84 612 4*1 uint32_t <invalid> '' 85 85 616 4*1 uint32_t <invalid> '' 86 86 620 4*1 uint32_t <invalid> '' 87 87 624 4*1 uint32_t <invalid> '' 88 88 628 4*1 uint32_t <invalid> '' 89 89 632 4*1 uint32_t <invalid> zero 90 0 636 8 long long <cooked> at 91 1 644 8 long long <cooked> v0 92 2 652 8 long long <cooked> v1 93 3 660 8 long long <cooked> a0 94 4 668 8 long long <cooked> a1 95 5 676 8 long long <cooked> a2 96 6 684 8 long long <cooked> a3 97 7 692 8 long long <cooked> t0 98 8 700 8 long long <cooked> t1 99 9 708 8 long long <cooked> t2 100 10 716 8 long long <cooked> t3 101 11 724 8 long long <cooked> t4 102 12 732 8 long long <cooked> t5 103 13 740 8 long long <cooked> t6 104 14 748 8 long long <cooked> t7 105 15 756 8 long long <cooked> s0 106 16 764 8 long long <cooked> s1 107 17 772 8 long long <cooked> s2 108 18 780 8 long long <cooked> s3 109 19 788 8 long long <cooked> s4 110 20 796 8 long long <cooked> s5 111 21 804 8 long long <cooked> s6 112 22 812 8 long long <cooked> s7 113 23 820 8 long long <cooked> t8 114 24 828 8 long long <cooked> t9 115 25 836 8 long long <cooked> k0 116 26 844 8 long long <cooked> k1 117 27 852 8 long long <cooked> gp 118 28 860 8 long long <cooked> sp 119 29 868 8 long long <cooked> s8 120 30 876 8 long long <cooked> ra 121 31 884 8 long long <cooked> sr 122 32 892 4 uint32_t <cooked> lo 123 33 896 8 long long <cooked> hi 124 34 904 8 long long <cooked> bad 125 35 912 8 long long <cooked> cause 126 36 920 8 long long <cooked> pc 127 37 928 8 long long <cooked> f0 128 38 936 8 double <cooked> f1 129 39 944 8 double <cooked> f2 130 40 952 8 double <cooked> f3 131 41 960 8 double <cooked> f4 132 42 968 8 double <cooked> f5 133 43 976 8 double <cooked> f6 134 44 984 8 double <cooked> f7 135 45 992 8 double <cooked> f8 136 46 1000 8 double <cooked> f9 137 47 1008 8 double <cooked> f10 138 48 1016 8 double <cooked> f11 139 49 1024 8 double <cooked> f12 140 50 1032 8 double <cooked> f13 141 51 1040 8 double <cooked> f14 142 52 1048 8 double <cooked> f15 143 53 1056 8 double <cooked> f16 144 54 1064 8 double <cooked> f17 145 55 1072 8 double <cooked> f18 146 56 1080 8 double <cooked> f19 147 57 1088 8 double <cooked> f20 148 58 1096 8 double <cooked> f21 149 59 1104 8 double <cooked> f22 150 60 1112 8 double <cooked> f23 151 61 1120 8 double <cooked> f24 152 62 1128 8 double <cooked> f25 153 63 1136 8 double <cooked> f26 154 64 1144 8 double <cooked> f27 155 65 1152 8 double <cooked> f28 156 66 1160 8 double <cooked> f29 157 67 1168 8 double <cooked> f30 158 68 1176 8 double <cooked> f31 159 69 1184 8 double <cooked> fsr 160 70 1192 4 uint32_t <cooked> fir 161 71 1196 4 uint32_t <cooked> '' 162 72 1200 4 uint32_t <cooked> '' 163 73 1204 4 uint32_t <cooked> '' 164 74 1208 4 uint32_t <cooked> '' 165 75 1212 4 uint32_t <cooked> '' 166 76 1216 4 uint32_t <cooked> '' 167 77 1220 4 uint32_t <cooked> '' 168 78 1224 4 uint32_t <cooked> '' 169 79 1228 4 uint32_t <cooked> '' 170 80 1232 4 uint32_t <cooked> '' 171 81 1236 4 uint32_t <cooked> '' 172 82 1240 4 uint32_t <cooked> '' 173 83 1244 4 uint32_t <cooked> '' 174 84 1248 4 uint32_t <cooked> '' 175 85 1252 4 uint32_t <cooked> '' 176 86 1256 4 uint32_t <cooked> '' 177 87 1260 4 uint32_t <cooked> '' 178 88 1264 4 uint32_t <cooked> '' 179 89 1268 4 uint32_t <cooked> *1: Inconsistent register sizes. (gdb) ----- Original Message ----- From: "Andrew Cagney" <ac131313@redhat.com> To: "Kris Warkentin" <kewarken@qnx.com> Cc: "Kevin Buettner" <kevinb@redhat.com>; "Gdb@Sources.Redhat.Com" <gdb@sources.redhat.com> Sent: Thursday, July 10, 2003 2:42 PM Subject: Re: mipsbe solib event breakpoint endian? > > Try `maint print {raw-,}registers' and `set debug target 1'. DanielJ's > >> hunch about swapping the low/high words looks right. > > > > > > I don't see any maint print registers commands....all I see are: > > > > architecture msymbols objfiles psymbols statistics > > symbols type > > That GDB is too old. You're missing both maint print registers and > maint print reggroups :-( > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-07-10 19:14 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-07-03 14:59 mipsbe solib event breakpoint endian? Kris Warkentin [not found] ` <1030708201312.ZM4704@localhost.localdomain> 2003-07-10 15:05 ` Kris Warkentin 2003-07-10 15:09 ` Daniel Jacobowitz 2003-07-10 15:15 ` Kevin Buettner 2003-07-10 15:33 ` Kris Warkentin 2003-07-10 17:05 ` Andrew Cagney 2003-07-10 17:16 ` Kris Warkentin 2003-07-10 18:42 ` Andrew Cagney 2003-07-10 19:14 ` Kris Warkentin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).