http://bugs.winehq.org/show_bug.cgi?id=32854
Bug #: 32854 Summary: Winedbg on ARM: gdb proxy mode lacks support for reading CPSR Product: Wine Version: 1.5.22 Platform: arm OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: winedbg AssignedTo: wine-bugs@winehq.org ReportedBy: focht@gmx.net Classification: Unclassified
Hello folks,
as the summary says ...
Any command will show the problem:
--- snip --- $ winedbg --gdb ./foo-arm.exe ... Wine-gdb> bt #0 0x4025202c in kill () from /lib/arm-linux-gnueabi/libc.so.6 Register 25 is not available --- snip ---
Making winedbg more verbose yields:
--- snip --- ... Packet: g Reply : 000000000500000000c00840103e00003c969f40300002408988000025000000000000000000000000000840fcfdcf408cc13e40f4fdcf4054a83a402c202540 Packet: p19 Register out of bounds 19 Reply : ... --- snip ---
GDB reads standard registers using the "g" command ('get all registers'). Special purpose registers like CPSR are read using "p" command ('get individual register'). This is currently not supported by winedbg but essential when running proxy mode.
Source: http://source.winehq.org/git/wine.git/blob/d62d7474d43949d71ac34e2157c2fdb83...
--- snip --- 372 #elif defined(__arm__) 373 static struct cpu_register cpu_register_map[] = { 374 REG(R0, 4), 375 REG(R1, 4), 376 REG(R2, 4), 377 REG(R3, 4), 378 REG(R4, 4), 379 REG(R5, 4), 380 REG(R6, 4), 381 REG(R7, 4), 382 REG(R8, 4), 383 REG(R9, 4), 384 REG(R10, 4), 385 REG(Fp, 4), 386 REG(Ip, 4), 387 REG(Sp, 4), 388 REG(Lr, 4), 389 REG(Pc, 4), 390 }; --- snip ---
Side note: For future it might be useful to add support for XML register set definitions (newer GDB versions are XML-aware = more flexible).
Regards
http://bugs.winehq.org/show_bug.cgi?id=32854
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com, | |nerv@dawncrow.de
http://bugs.winehq.org/show_bug.cgi?id=32854
--- Comment #1 from André H. nerv@dawncrow.de 2013-01-31 13:13:58 CST --- If the order in [1] and [2] is the one to choose, then i first need to get the floatingpoint thing into the context. That sounds like a hard job on ARM as every processor/soc/platform is different...
[1] http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/arm-tdep.c?rev=1.374&co... [2] http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/arm-tdep.h?rev=1.58&con...
http://bugs.winehq.org/show_bug.cgi?id=32854
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@orange.fr
--- Comment #2 from André H. nerv@dawncrow.de 2013-02-13 11:03:00 CST --- I had a closer look and it's not that easy, because on Windows the floating points are structs/unions in CONTEXT with 128 bit and we can't handle that yet. Also i don't understand which size gdb would expect. There are different sizes possible depending on the cpu/compiler (e.g. soft, softfp, hard). Eric, can you please help us here?
http://bugs.winehq.org/show_bug.cgi?id=32854
--- Comment #3 from Anastasius Focht focht@gmx.net 2013-02-13 17:47:29 CST --- Hello André,
maybe providing an XML target (register) description "target.xml" to GDB is an easier way without the need to deal with that messy Soft/HW/VFP support right now. This feature query is supported for some years now, starting with GDB 6.7.
See: http://sourceware.org/gdb/current/onlinedocs/gdb/Target-Descriptions.html ("Target Descriptions")
http://sourceware.org/gdb/onlinedocs/gdb/Target-Description-Format.html
Also: https://code.google.com/p/nativeclient/issues/detail?id=2911 (Google NACL, make the debug stub work on ARM - they encountered the same problem with supporting CPSR).
--- quote --- // Without this XML description, ARM GDB assumes a default register // set with floating point registers f0-f7 and fps between pc and // cpsr, and GDB queries CPSR via the "p" command for reading a single // register. static const char XmlArm[] = "<feature name="org.gnu.gdb.arm.core">\n" " <reg name="r0" bitsize="32" type="uint32"/>\n" " <reg name="r1" bitsize="32" type="uint32"/>\n" " <reg name="r2" bitsize="32" type="uint32"/>\n" " <reg name="r3" bitsize="32" type="uint32"/>\n" " <reg name="r4" bitsize="32" type="uint32"/>\n" " <reg name="r5" bitsize="32" type="uint32"/>\n" " <reg name="r6" bitsize="32" type="uint32"/>\n" " <reg name="r7" bitsize="32" type="uint32"/>\n" " <reg name="r8" bitsize="32" type="uint32"/>\n" " <reg name="r9" bitsize="32" type="uint32"/>\n" " <reg name="r10" bitsize="32" type="uint32"/>\n" " <reg name="r11" bitsize="32" type="uint32"/>\n" " <reg name="r12" bitsize="32" type="uint32"/>\n" " <reg name="sp" bitsize="32" type="data_ptr"/>\n" " <reg name="lr" bitsize="32"/>\n" " <reg name="pc" bitsize="32" type="code_ptr"/>\n" " <reg name="cpsr" bitsize="32" regnum="25"/>\n" "</feature>\n"; --- quote ---
The current "cpu_register_map" way is inflexible because it assumes array index = GDB register index (no holes).
Regards
http://bugs.winehq.org/show_bug.cgi?id=32854
--- Comment #4 from Eric Pouech eric.pouech@orange.fr 2013-02-17 02:58:07 CST --- André, not sure what you're expecting for help :-( but anyway, in the worst case there are several formats you have to deal with: - the linux context format (read/written by wine server) (and converted into next one) - the windows CONTEXT (retrieved from server by gdb proxy) - the format on the "wire" (between gdb and it's proxy)
as of today, we don't really support sending floats on the wire (especially if format in CONTEXT doesn't match format on the wire) we do have support for changing format for integers
you first have to understand the format gdb expects on the wire
XML won't help you much here (as this format mapping has to be taken care of anyway) XML will help if you don't want to support all registers (you can cherry pick the ones you implement), while current implement mode implies having no holes in range of registers
A+
http://bugs.winehq.org/show_bug.cgi?id=32854
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|wine-bugs@winehq.org |nerv@dawncrow.de
--- Comment #5 from André H. nerv@dawncrow.de 2013-02-23 07:15:54 CST --- (In reply to comment #4)
XML will help if you don't want to support all registers (you can cherry pick the ones you implement), while current implement mode implies having no holes in range of registers
I'm working on it now.
http://bugs.winehq.org/show_bug.cgi?id=32854
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |2d449b76e1b604af5d524c1f613 | |833d1f47c3466 Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #6 from André H. nerv@dawncrow.de 2013-02-26 15:17:34 CST --- should be fixed with 2d449b76e1b604af5d524c1f613833d1f47c3466
http://bugs.winehq.org/show_bug.cgi?id=32854
--- Comment #7 from Alexandre Julliard julliard@winehq.org 2013-03-01 14:50:25 CST --- Closing bugs fixed in 1.5.25.
http://bugs.winehq.org/show_bug.cgi?id=32854
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org 2013-03-01 15:09:49 CST --- Really closing bugs fixed in 1.5.25.
https://bugs.winehq.org/show_bug.cgi?id=32854
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|nerv@dawncrow.de |wine-bugs@winehq.org