Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Memory view and monitor

> And the memory view is still doing byte accesses anyway [...]

Is GDB doing byte accesses to the target still? i.e. memory view/CDT will issue -data-read-memory-bytes, but I expect GDB to issue to target aligned word reads to fill that region. The -data-read-memory-bytes uses read_memory_robust which takes into account memory regions which in turn uses target_read which also does.

I don't have a suitable board setup at the moment for debugging/reproducing this.

Jonah 

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Wed, 29 Jan 2020 at 10:06, <Anton.Krug@xxxxxxxxxxxxx> wrote:
> mem 0 0 rw 32 cache
Should this affect the alignment and accesses how the memory viewer accesses the data?

info mem
Using user-defined memory regions.
Num Enb Low Addr   High Addr  Attrs
1   y   0x00000000 0x100000000 rw 32 cache

And the memory view is still doing byte accesses anyway, or am I doing something stupid?

I wouldn't say the downstream tooling necessary needs to know. If the memoryview could fetch the mem regions from the gdb then it would be great. But this doesn't have to make 100% robust accesses from all levels, sometimes you want to do odd stuff, sometimes you want to on lower level go into the unimplemented region, or trigger an exception. This is more to safeguard the basic usage where just a simple opening of the memory view can break the system.

We do a bit of this on our arms where we set what regions are read and which are read/write so the OpenOCD knows better what types of breakpoints are safe where. Before these things were hardcoded, but it was not suiting our HW as it was more configurable and different than typical ARM targets. So be able to describe the peripheral regions and whatnut through this would be great. But I understand it correctly that memory view now is not fetching the info mem information? Instead of inventing new scheme using the gdb mem would be great. The configuration doesn't have to UI, if there is a way to make sure first it works well.

Then for finer granularity detail (what registers are safe to read/write and what side effects they have) would be good to do on the SVD/Peripheral gme-packs level. Liviu, is this what you are referencing 'GME Peripheral Registers viewer', or is there something else as well? I tried the packs and made a specific peripheral and then the peripheral open in the memory view, so it is inheriting the issues of the memory viewer? Except that the SVD looks perfect.
From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Jonah Graham <jonah@xxxxxxxxxxxxxxxx>
Sent: 29 January 2020 01:37
To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] Memory view and monitor
 
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 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. For example, even if CDT's memory view "understood" memory alignment and allowable regions, that would not help users who typed in the Debugger Console, nor would it prevent derefrencing pointer variables to the same memory. In both of these cases CDT's memory view is not involved. 

The way to inform GDB what is safe and what alignment, etc, is to use GDB's mem and related commands[1]. Does that set of commands address your needs? If so, then what may make sense is to provide UI in CDT to setup GDB if the GDB and its associated backend don't have support for that already. And, even if GDB and its backend support memory regions, then UI to visualize that would be useful, within the Memory view or in a dedicated UI/view.

Finally, it would not surprise me if there are some flow and presentation issues in the Memory views when memory regions are defined. I hope that fixing such issues are not controversial and can be for the common good.


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Tue, 28 Jan 2020 at 16:37, Liviu Ionescu <ilg@xxxxxxxxxx> wrote:


> On 28 Jan 2020, at 20:32, <Anton.Krug@xxxxxxxxxxxxx> <Anton.Krug@xxxxxxxxxxxxx> wrote:
>
> ... When I use the memory view and try to access our embedded HW target, I run into issues.

I'm afraid that when the memory viewer was designed, these embedded specific issues were not considered... :-(

I remember in the GME Peripheral Registers viewer I had to be extra careful with access sizes and alignments, and I'm not sure I correctly covered all cases, especially those reads with side effects, that must not be performed with all refreshes.

So in this area some extra work might be needed.


Regards,

Liviu








_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

Back to the top