OK, I am staring to get this. After looking more thoughly how it is implementer in other architectures, I think that : 1) We use target_write_u32() to write instructions defined on the host (in host endianess) to target. This function transform MIPS32_SDBBP from host (usualy PC with LE) to good endianess on the target
2) target_read_memory() is needed to get to the host the bytes of original instruction in *target* endianes. Comparing these bytes with something on host makes no sense if not host and target differ in endianess and read bytes are not adapted before comparisons with target_buffer_get_u32(target, (uint8_t *)¤t_instr), and this is what is currently missing in MIPS32 implementation 3) Whenever target_read_memory() to get original instruction, then target_write_memory() must be used to write it back. Pairing target_read_memory() with target_write_u32() is wrong, as first will preserve target endianess, and second will do transformation from host endiness to target endiness. Suppose that target is BE and host is LE - then target_read_memory() will get BE bytes to the host, and target_write_u32() will take these bytes, consider them as LE (because it thinks that it is some host's data) and flip them again to be BE. However, target_write_memory() will think that these bytes to be written are already BE (because it will know that it is target, and not host's data - just temporarily lives on the host in breakpoint->orig_instr), and will not flip them. So, with this in mind, I will try to add just a missing line and do some tests tomorrow. BTW, target_write_memory() and target_write_u32() is not the luckiest function name choice, as they have different behaviors... BR, Drasko On Wed, Jun 29, 2011 at 2:47 PM, Drasko DRASKOVIC <[email protected]> wrote: > Hi all, > I have additional questions about target_read_memory() and > target_read_u32() used to set/unset breakpoints. > > I can see that target_read_memory() simply calls > mips_m4k_write_memory() and since I have big endian MIPS target, bytes > are not swapped. > > However, target_read_u32(), besides calling target_read_memory(), it > also swappes the bytes returned (I pasetd the function definition > below). > > > Would that mean that all the time when we want to read 4 or 2 bytes > values, like breakpoints instructions, we must *always* use > target_read_u32 and target_read_u16, and never target_read_memory() ? > > If answer is yes, I'll change rest of the file where this should be > done, and post more complete patch. > > Best regards, > Drasko > > > > > int target_read_u32(struct target *target, uint32_t address, uint32_t *value) > { > uint8_t value_buf[4]; > if (!target_was_examined(target)) > { > LOG_ERROR("Target not examined yet"); > return ERROR_FAIL; > } > > int retval = target_read_memory(target, address, 4, 1, value_buf); > > if (retval == ERROR_OK) > { > *value = target_buffer_get_u32(target, value_buf); > LOG_DEBUG("address: 0x%8.8" PRIx32 ", value: 0x%8.8" PRIx32 "", > address, > *value); > } > else > { > *value = 0x0; > LOG_DEBUG("address: 0x%8.8" PRIx32 " failed", > address); > } > > return retval; > } > > On Mon, Jun 27, 2011 at 8:31 PM, Drasko DRASKOVIC > <[email protected]> wrote: >> Hi all, >> I've noticed that unsetting soft breaks is currently broken on BE MIPS >> 4Kc targets. >> >> This patch fix it by using target_read_u32() and target_read_u16() >> instead of target_read_memory(). >> >> BR, >> Drasko >> > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
