This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 02/25] Adjust the order of 32bit-linux.xml and 32bit-sse.xml in i386/i386-linux.xml
Pedro Alves <palves@redhat.com> writes:
This patch doesn't change the registers layout in gdbserver, because
gdb/regformats/i386/i386-linux.dat isn't affected by this patch. It
determines the register layout for i386-linux, in which "orig_eax" is
already put the end of list, thanks to sort-regs.xsl.
This patch only changes the order of iterating features and registers in
GDB, however, the order doesn't matter.
> It may be easy to check against gdbserver. You'd need to hack it to
> disable the x86 xml tdesc support, which is a relatively
> recent addition. [It took a while for the x86 port to support xml
> tdescs]. The xmlRegisters= qSupported feature had to invented to
> keep backward compatibility back then.
>
> E.g., hack gdb's remote.c:register_remote_support_xml, or
> gdbserver's linux-x86-low.c:x86_linux_process_qsupported.
> If, with x86 XML support disabled, before vs after patch the
> layout of GDB's g/G packet buffer changes, then you have
> a back compatibility break.
I hacked remote.c:register_remote_support_xml like this,
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -4711,6 +4711,7 @@ void
register_remote_support_xml (const char *xml)
{
#if defined(HAVE_LIBEXPAT)
+#if 0
if (remote_support_xml == NULL)
remote_support_xml = concat ("xmlRegisters=", xml, (char *) NULL);
else
@@ -4735,6 +4736,7 @@ register_remote_support_xml (const char *xml)
(char *) NULL);
}
#endif
+#endif
}
static char *
---
so GDB doesn't send qSupported:xmlRegisters=i386, and as a result,
GDBserver doesn't reply GDB about the target description registers,
Sending packet: $qXfer:features:read:target.xml:0,fff#7d...Packet received: l<target><architecture>i386</architecture><osabi>GNU/Linux</osabi></target>
The GDB's understanding to g/G packet layout is not changed, verified by
"maintenance print remote-registers",
(gdb) maintenance print remote-registers
Name Nr Rel Offset Size Type Rmt Nr g/G Offset
eax 0 0 0 4 int32_t 0 0
ecx 1 1 4 4 int32_t 1 4
edx 2 2 8 4 int32_t 2 8
ebx 3 3 12 4 int32_t 3 12
esp 4 4 16 4 *1 4 16
ebp 5 5 20 4 *1 5 20
esi 6 6 24 4 int32_t 6 24
edi 7 7 28 4 int32_t 7 28
eip 8 8 32 4 *1 8 32
eflags 9 9 36 4 i386_eflags 9 36
cs 10 10 40 4 int32_t 10 40
ss 11 11 44 4 int32_t 11 44
ds 12 12 48 4 int32_t 12 48
es 13 13 52 4 int32_t 13 52
fs 14 14 56 4 int32_t 14 56
gs 15 15 60 4 int32_t 15 60
st0 16 16 64 10 _i387_ext 16 64
st1 17 17 74 10 _i387_ext 17 74
st2 18 18 84 10 _i387_ext 18 84
st3 19 19 94 10 _i387_ext 19 94
st4 20 20 104 10 _i387_ext 20 104
st5 21 21 114 10 _i387_ext 21 114
st6 22 22 124 10 _i387_ext 22 124
st7 23 23 134 10 _i387_ext 23 134
fctrl 24 24 144 4 long 24 144
fstat 25 25 148 4 long 25 148
ftag 26 26 152 4 long 26 152
fiseg 27 27 156 4 long 27 156
fioff 28 28 160 4 long 28 160
foseg 29 29 164 4 long 29 164
fooff 30 30 168 4 long 30 168
fop 31 31 172 4 long 31 172
xmm0 32 32 176 16 vec128 32 176
xmm1 33 33 192 16 vec128 33 192
xmm2 34 34 208 16 vec128 34 208
xmm3 35 35 224 16 vec128 35 224
xmm4 36 36 240 16 vec128 36 240
xmm5 37 37 256 16 vec128 37 256
xmm6 38 38 272 16 vec128 38 272
xmm7 39 39 288 16 vec128 39 288
mxcsr 40 40 304 4 i386_mxcsr 40 304
'' 41 41 308 0 int0_t
'' 42 42 308 0 int0_t
'' 43 43 308 0 int0_t
'' 44 44 308 0 int0_t
'' 45 45 308 0 int0_t
'' 46 46 308 0 int0_t
'' 47 47 308 0 int0_t
'' 48 48 308 0 int0_t
'' 49 49 308 0 int0_t
'' 50 50 308 0 int0_t
'' 51 51 308 0 int0_t
'' 52 52 308 0 int0_t
'' 53 53 308 0 int0_t
'' 54 54 308 0 int0_t
'' 55 55 308 0 int0_t
'' 56 56 308 0 int0_t
'' 57 57 308 0 int0_t
'' 58 58 308 0 int0_t
'' 59 59 308 0 int0_t
'' 60 60 308 0 int0_t
'' 61 61 308 0 int0_t
'' 62 62 308 0 int0_t
'' 63 63 308 0 int0_t
'' 64 64 308 0 int0_t
'' 65 65 308 0 int0_t
'' 66 66 308 0 int0_t
'' 67 67 308 0 int0_t
'' 68 68 308 0 int0_t
'' 69 69 308 0 int0_t
'' 70 70 308 0 int0_t
'' 71 71 308 0 int0_t
orig_eax 72 72 308 4 long 41 308
al 73 0 312 1 int8_t
cl 74 1 313 1 int8_t
dl 75 2 314 1 int8_t
bl 76 3 315 1 int8_t
ah 77 4 316 1 int8_t
ch 78 5 317 1 int8_t
dh 79 6 318 1 int8_t
bh 80 7 319 1 int8_t
ax 81 8 320 2 int16_t
cx 82 9 322 2 int16_t
dx 83 10 324 2 int16_t
bx 84 11 326 2 int16_t
'' 85 12 328 2 int16_t
bp 86 13 330 2 int16_t
si 87 14 332 2 int16_t
di 88 15 334 2 int16_t
mm0 89 16 336 8 _vec64i
mm1 90 17 344 8 _vec64i
mm2 91 18 352 8 _vec64i
mm3 92 19 360 8 _vec64i
mm4 93 20 368 8 _vec64i
mm5 94 21 376 8 _vec64i
mm6 95 22 384 8 _vec64i
mm7 96 23 392 8 _vec64i
however, I can't verify that GDBserver's understanding to g/G packet
layout is not changed, unless we write a unit test, but as I analyzed
above, the layout in GDBserver side doesn't change.
--
Yao (齐尧)