[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Addressable unit in memory viewer display
|
On Tuesday 08 July 2008 16:35:21 Sebastian Paluch wrote:
> Hello,
>
>
>
> We are working on PowerPc MPC5554 and having problems with memory view
> when trying to see peripheral registers regions.
>
> In following example Eclipse is asking about 100 bytes reading one by
> one:
>
>
>
> 400-data-read-memory 4294197248 x 1 1 100
>
> 400^done,addr="0xfff44000",nr-bytes="100",total-bytes="100",next-row="0x
> fff44064",prev-row="0xfff43f9c",next-page="0xfff44064",prev-page="0xfff4
> 3f9c",memory=[{addr="0xfff44000",data=["0x00","0x00","0x00","0x00","0x00
> ","0x00","0x00","0x03","0xc3","0xf8","0x40","0x2c","0xff","0xf8","0x00",
> "0x42","0x40","0x04","0x0f","0xf0","0x20","0x28","0x63","0x6f","0x40","0
> x00","0x56","0x60","0x53","0x70","0x69","0x44","0x65","0x73","0x63","0x7
> 2","0x69","0x70","0x74","0x6f","0x72","0x53","0x74","0x20","0x2a","0x29"
> ,"0x2e","0x00","0x42","0x75","0x73","0x48","0x64","0x6c","0x2d","0x3e","
> 0x4d","0x6f","0x64","0x75","0x94","0x21","0xff","0xf0","0x94","0x21","0x
> ff","0xf0","0x94","0x21","0xff","0xf0","0x94","0x21","0xff","0xf0","0x94
> ","0x21","0xff","0xf0","0x94","0x21","0xff","0xf0","0xff","0xf9","0x00",
> "0x00","0xff","0xf9","0x40","0x00","0xff","0xf9","0x80","0x00","0xff","0
> xf9","0xc0","0x00"]}]
>
>
>
> But register in this location
What is "this location" -- it appears that the output above is perfectly
fine.
> are not byte accessible, but four bytes.
>
> Direct gdb call fails when not byte accessible address is reached,
> data-read-memory command does not instead it returns garbage's.
What do you mean by "garbase". In GDB 6.8, the -data-read-memory would return
error (for the entire operation) if it find any memory error. The CVS HEAD version
of GDB will return all the memory until the first error, and return "n/a" for
the reminder of the requested memory region, which Eclipse shows using "?"
But it seems something is wrong with the target. GDB does not read the memory
byte-by-byte -- it issues a read request for 100 bytes. It's up to your target
to produce those 100 bytes in whatever way is suitable. Also, it's not apparent
to me why your target would refuse byte access -- is reading the memory location
has some side effects? If no, then I think reading individual bytes will be OK.
> Because of those issues Expression resolving is also not working when
> operating the same memory i.e. (*( struct EDMA_tag *) 0xFFF44000)
> is not showing correct values.
I don't understand you. When this expression is evaluated, GDB is supposed
to read sizeof(EDMA_tag) bytes from the target. I would have hoped this
size to be multiple of 4, if it mirrors hardware registers layout. Then,
I don't see where error comes from -- except if the structure is as large
as not to fit in one memory transfer.
> Is there any way to make it working?
It seems this is an issue with your target, not with CDT.
- Volodya
