Re: [cdt-debug-dev] Memory view

["Alain Magloire" <alain@xxxxxxx>]

Bonjour,

> I take for example a DSP that has a Minumum Addressable Unit of 24 bits, 
> short integer are on 24 bits and long on 48 bits.
> When Eclipse ask the debugger for a memory block, he's returning 24 bits 
> per memory address.
> Example of the MI output:
> -data-read-memory 0x8ca x 1 1 6
> ^done,addr="0x8ca",nr-bytes="6",total-bytes="6",next-row="0x8d0",prev-row="0x8c4",next-page="0x8d0",prev-page="0x8c4",memory=[{addr="0x8ca",data=["0x000000","0xffffff","0xfffffe","0xfffffd","0xfffffc","0xfffffb"]}]
> 
> But Eclipse memory view truncates the first 16bits and take only the 8 
> least significant bits to display memory area.
> I think MAU could be calculated by Eclipse the first time he gets a 
> memory block by checking the output of data memory returns by the 
> debugger, counting its number of characters. "0x000000" would mean 24 
> bits, "0x0000" 16 bits and "0x00" 8 bits MAU. The MI standard fits this 
> requirement.
> 

Yes, agreed.
But It should probably be done in the CDT/MI layer.
Can you make a PR for this in the bugzilla Database for CDT, with this email quoted ?
That will help us track this for the next version.

Next question do you know of a command in gdb that will return MAU.

> 
> Taking that into account, may be you'll tell me "we won't be able to 
> display 24bits integers or 48 bits long datas".
> An other point we notice is that today, the memory view emits MI command 
> -data-read-memory with word-format parameter always set to hexadecimal, 
> that means Eclipse computes these values before displaying them.
>  
> We think it's the job of the debugger to know how to display the data he 
> is accessing, not to the interface. We think the best solution to avoid 
> wrong display is to use ouputs formats as defined in chap. 8.4 of GdB 
> 6.3 documentation (integer, signed or unsigned, octal ...), then 
> debugger will return correctly formatted datas, with sign bits correctly 
> set according to the processor Architecture and so on.
> 

Ok.

> We noticed this problem/behaviour in other part of Eclipse like the 
> register view who performs its own formatting without taking care of 
> register size but only register type, assuming that type of the debbuged 
> processor is the same as type of the machine which run Eclipse.
> 
> Please don't hesitate to ask me for details or explanation

Then can you help us by making PRs in bugzilla so we can address the issues
And if we need to escalate the issue, because it is a flaw in Eclipse not CDT ... we will ... gladly 8-)


Merci Buckets, for catching this.