If GDB is expecting the target values to be in target endianness, then it should probably be fixed in the gdb server so it works for all targets. For modular applications, the general practice is to define the endianness used for a given module. For example, it might be reasonable for the target code to keep everything in target endianness, the gdb module to use target endianness, the telnet module to use host endianness, etc. That makes it much easier to keep track of and ensures that if you follow the convention for a given module, everything will interact nicely. By changing this in the target only, the next developer to come along won't realize that all of the GDB server functionality is supposed to return target endianness and not all the targets will use the correct endianness for get_gdb_reg_list().

Rick


On Nov 13, 2008, at 12:06 PM, quba54 Gazeta.pl wrote:

I make changes in functions:
- arm7_9_set_breakpoint(),arm7_9_unset_breakpoint() – I think it's clear to understand - armv4_5_get_gdb_reg_list() - registers in target->reg_cache variable are stored in host endianes (little endian) so if target is configured to work in big endian GDB expects data returned formatted in big endian. In original version register values was always returned in little endian. I declared additional variable tmp_regs[26] holding values converted to target endiannes and returning it to upper layer (gdb_server.c). I also add function armv4_5_get_real_reg() to transform tmp_regs[i] to real register from target->reg_cache variable. Maybe it can be done in more clear way but I'm beginner in openocd sources and I needed fast solution to debug my big endian target.



2008/11/13 Øyvind Harboe <[EMAIL PROTECTED]>
On Thu, Nov 13, 2008 at 9:49 AM, quba54 Gazeta.pl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Recently I also had to debug big endian arm7 target (mac7111) and I make
> some modifications in openocd source code. See attachment.

Please explain a bit more what you have done and why.

Thanks!




--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer

_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

--
Rick Altherr
[EMAIL PROTECTED]

"He said he hadn't had a byte in three days. I had a short, so I split it with him."
 -- Slashdot signature


Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to