[Cbe-oss-dev] spufs, ppu-gdb: ppu-gdb's info spu mailbox shows garbage

[Arnd Bergmann]

On Tuesday 16 October 2007, Kazunori Asayama wrote:

>    That is,
> 
>        man page:
> 
>            - mbox_info, ibox_info and wbox_info retun all entries of
>              the queues.
> 
>        implementation:
> 
>            - wbox_info returns only valid entries.
>        	   - mbox_info and ibox_info return all entries.
> 
>        	   It seems odd that there is such difference between the
>        	   actual behaviors of wbox_info, mbox_info and ibox_info...

From reading the source code, it looks like they should all just return
the valid entries. mbox_info and ibox_info may return data from the kernel
stack, which is definitely not allowed and the code needs to be changed.

When we change that code, it seems reasonable to make it all behave like
the wbox_info, which is at least working fine, even though it's different
from the man page.
 
> 2. ppu-gdb's "info spu mailbox" command shows garbage when there are
>    invalid entries in "ibox_info" and/or "mbox_info".
> 
>    The current "info spu mailbox" command implementation,
>    i.e. info_spu_mailbox_command() in gdb/spu-tdep.c, shows all data
>    returned by mbox_info, ibox_info and wbox_info.
> 
>    However, garbage can be displayed because mbox_info and ibox_info
>    return invalid values when they are not full.

Right, this is a result of the kernel returning incorrect data.

> My question is "what is the intended behavior?" I guess that one of
> following a. or b. is intended one:
> 
>     a. - mbox_info, ibox_info and wbox_info should return only valid
>          entries; i.e. the man page is incorrect.
> 
>        - gdb should show the all data returned by mbox_info, ibox_info
>          and wbox_info; i.e. the current implementation is correct.

Yes, we should fix the kernel for ibox_info and mbox_info, then adapt
the man page. Another reason to do it this way is that the architecture
does not specify how many elements can be in each mailbox, so we should
not encode that into the kernel interface either.

	Arnd <><