[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Memory view and monitor
|
> On 29 Jan 2020, at 03:37, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
>
> > I'm wondering is there a cheap/easy trick to at least force it to 32-bit mode and maybe limit range which will be allowed to access?
>
> I think you can do this in the Debugger Console (or gdbinit)[1]:
> mem 0 0 rw 32 cache
>
> ---
>
> > I'm afraid that when the memory viewer was designed, these embedded specific issues were not considered... :-(
>
> This is an interesting topic. As far as I understood, this topic involves GDB and downstream tooling.
If I understood Anton's message right, this does involve the CDT debugging plug-ins.
Let me try to rephrase (Anton, please correct me if I'm wrong):
When a memory view is created, the user needs to enter an address and possibly some formatting info. The CDT plug-in then fetches content from a range of addresses and displays it. Each time execution stops, the view is refreshed.
This works fine for reading RAM in a user space linux/windows application, but has some challenges in an embedded environment.
For example, since there is only a begin address and no end address, and the plug-in tries to fill a screen page, creating a memory view with the address of the last word in the RAM space will generally try to read past the physical memory end possibly throw an exception.
Same for the access size, there is no way to ask the plug-in to issue access of 4 bytes, so it can issue requests of any size.
It is true that the reads are performed by GDB, but the range of the accesses and the granularity is controlled by the plug-in.
In other words, simply specifying the begin address is not enough, probably it would be safer to add the end address, word size and the alignment.
The GME Peripheral Registers viewer is inspired by the memory viewer, but since it has a better knowledge of the hardware from the SVD, it can issue accesses that match the registers sizes, and can also avoid going into non defined areas.
Regards,
Liviu