Can gdb handle aliased memory regions ?

Can gdb handle aliased memory regions ?

[MikeW]

Target platform: STLinux / ST Micro Connect

On the target CPU, there is one region of physical memory that is accessible by
two different mapped memory address regions: one as cached memory and one as
uncached, eg.
 0x8000000 (virt cached)   -> 0x40000000 (phys)
 0xDF00000 (virt uncached) -> 0x40000000 (phys)

During the kernel init, there is a code sequence which switches between cached
and uncached (to update cache registers etc) and expects the execution to
proceed from eg. 0x80001234 to 0xDF001236.

Stepping with gdb is fine until the switchover point is reached,
whereupon gdb thinks it's lost control ('step[i]', 'next' or 'finish'
do not return to the (gdb) prompt), but of course the ms bits of
the PC just refer to the other region.

I note gbd has support for the older technique of overlays; is there any way to
tell gdb that the 0x8000... and 0xDF00... regions are actually the same physical
memory ?

Thanks.

Re: Can gdb handle aliased memory regions ?

[Kevin Pouget]

On Wed, Oct 12, 2011 at 5:35 PM, MikeW <mw_phil@yahoo.co.uk> wrote:
> Target platform: STLinux / ST Micro Connect
>
> On the target CPU, there is one region of physical memory that is accessible by
> two different mapped memory address regions: one as cached memory and one as
> uncached, eg.
>  0x8000000 (virt cached)   -> 0x40000000 (phys)
>  0xDF00000 (virt uncached) -> 0x40000000 (phys)
>
> During the kernel init, there is a code sequence which switches between cached
> and uncached (to update cache registers etc) and expects the execution to
> proceed from eg. 0x80001234 to 0xDF001236.
>
> Stepping with gdb is fine until the switchover point is reached,
> whereupon gdb thinks it's lost control ('step[i]', 'next' or 'finish'
> do not return to the (gdb) prompt), but of course the ms bits of
> the PC just refer to the other region.
>
> I note gbd has support for the older technique of overlays; is there any way to
> tell gdb that the 0x8000... and 0xDF00... regions are actually the same physical
> memory ?
>
> Thanks.

stlinux kernel debugger maintainer cc'd

RE: Can gdb handle aliased memory regions ?

[Marc TITINGER]

Hi Mike,

> -----Original Message-----
> From: Kevin Pouget [mailto:kevin.pouget@gmail.com]
> Sent: Thursday, October 13, 2011 6:16 PM
> To: gdb@sources.redhat.com
> Cc: MikeW; Marc TITINGER
> Subject: Re: Can gdb handle aliased memory regions ?
> 
> On Wed, Oct 12, 2011 at 5:35 PM, MikeW <mw_phil@yahoo.co.uk> wrote:
> > Target platform: STLinux / ST Micro Connect
> >
> > On the target CPU, there is one region of physical memory that is
> accessible by
> > two different mapped memory address regions: one as cached memory and
> one as
> > uncached, eg.
> >  0x8000000 (virt cached)   -> 0x40000000 (phys)
> >  0xDF00000 (virt uncached) -> 0x40000000 (phys)

Is it 0xDF00000 or 0xDF00_0000 like below in this text ? I'm asking because in the first case it looks like a VM (usermode) to Phy translation issue (I'm assuming it is a Linux kernel), while below, it looks like a kernel to physical memory mapping question ? 


> >
> > During the kernel init, there is a code sequence which switches
> between cached
> > and uncached (to update cache registers etc) and expects the
> execution to
> > proceed from eg. 0x80001234 to 0xDF001236.
So IIUC, you are running kernel code and at that point you which to tell the debugger to use a different offset and resume. Maybe the kernel has a meminfo.bank dedicated to the uncached mapping that we could use.

> >
> > Stepping with gdb is fine until the switchover point is reached,
> > whereupon gdb thinks it's lost control ('step[i]', 'next' or 'finish'
> > do not return to the (gdb) prompt), but of course the ms bits of
> > the PC just refer to the other region.
> >
> > I note gbd has support for the older technique of overlays; is there
> any way to
> > tell gdb that the 0x8000... and 0xDF00... regions are actually the
> same physical
> > memory ?
AFAIK the linux-awareness target does not support this currently unfortunately, but it would be easy to add a command to switch the memory bank from the tty at that point. 

May I ask you to send me the type of SoC, stlinux and gdb versions you are using ?

Many thanks,
Marc. 
 

> >
> > Thanks.
> 
> stlinux kernel debugger maintainer cc'd

Re: Can gdb handle aliased memory regions ?

[MikeW]

Marc TITINGER <Marc.TITINGER <at> st.com> writes:
> 
> Hi Mike,
> 
> AFAIK the linux-awareness target does not support this currently
unfortunately, but it would be easy to
> add a command to switch the memory bank from the tty at that point. 
> 
> May I ask you to send me the type of SoC,
 stlinux and gdb versions you are using ?
> 

Marc,

It's STLinux-2.3 (for compatibility reasons), 7114 device, gdb 6.8-44
"build Oct 27 2009" --target=sh4-linux
It is kernel code.
This is not a showstopper, just a convenience matter, really.

Thanks,
Mike

> Many thanks,
> Marc. 
> 

Re: Can gdb handle aliased memory regions ?

[Tom Tromey]

>>>>> "MikeW" == MikeW  <mw_phil@yahoo.co.uk> writes:

MikeW> I note gbd has support for the older technique of overlays; is
MikeW> there any way to tell gdb that the 0x8000... and
MikeW> 0xDF00... regions are actually the same physical memory ?

I don't know of one.

I think we'd accept a clean patch to add it.

Tom