On Thu, Jul 7, 2011 at 12:59 AM, Andreas Fritiofson
<andreas.fritiof...@gmail.com> wrote:
> No, casting a pointer-to-any-type to a pointer-to-void and back will never
> cause alignment issues. The question is who makes the guarantee that the
> function is only ever called with uint32-aligned generic pointers. If it
> just happens to be so that all *current* callers pass a uint32 pointer cast
> to void pointer, it would be a terribly bad idea to suddenly assume that. If
> it is guaranteed by design/contract, why is a void pointer used at all? Just
> use a pointer to uint32 then.
>
> I have no experience with the MIPS code or arch at all, but if it was up to
> me I'd prefer if a *_read_mem function didn't interpret the data and thus it
> should deal with void pointers.
I see no other way... Actually, any data you want to write must be
transfered to 32-bit value put to the register... Acutually, it is
transformed in 32-bit parameter, put onto the miniprogram EJTAG stack,
and then copied in the miniprogram (a small Monitor ROM, if you want,
written dynamically via dongle) to register. This register is the
written to RAM.
Now, there must be a way to put 8-bit values to EJTAG stack and then
just put this 8 bits into the reg in a miniprogram, but that would
demand quite a bit of changes of assembly bytecode miniprograms, IMHO.
I don't know at this point, I'll have to study MIPS code more throughly.
> It would by design be totally free from all
> endian issues and conversions. Moreover, a function accepting a
> pointer-to-void should be prepared to handle any kind of alignment thrown at
> it (unless explicitly stated). That excludes direct casts to uint32_t*.
>> That's why GCC is complaining. Sometimes...
>
>
> It should never complain when casting a generic pointer to another pointer,
> right? You shouldn't even need an explicit cast IIRC.
Where param_in is uint32_t*, and buf is uint8_t* ?
Is is maybe because of code like this :
for (i = 0; i < count; i++)
{
param_in[i + 2] = buf[i];
}
Dunno... I never seen the warnings so far...
BR,
Drasko
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
