* Re: needs writeback on ptrace
2008-02-15 0:52 needs writeback on ptrace Hideo Saito
@ 2008-02-15 5:29 ` Paul Mundt
2008-02-15 7:40 ` Hideo Saito
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Paul Mundt @ 2008-02-15 5:29 UTC (permalink / raw)
To: linux-sh
On Fri, Feb 15, 2008 at 09:52:54AM +0900, Hideo Saito wrote:
> Hi Paul,
>
> When I test gdb on linux-2.6.24 for SH7780, the gdb can't step the program.
> I think inserted breakpoints can't write back to the physical memory.
>
> Following changes is available for this problem.
>
> --- ./arch/sh/mm/pg-sh4.c.org 2008-01-25 07:58:37.000000000 +0900
> +++ ./arch/sh/mm/pg-sh4.c 2008-02-06 17:19:58.000000000 +0900
> @@ -87,18 +109,21 @@ void copy_to_user_page(struct vm_area_st
> void *vto;
>
> __set_bit(PG_mapped, &page->flags);
>
> vto = kmap_coherent(page, vaddr) + (vaddr & ~PAGE_MASK);
> memcpy(vto, src, len);
> kunmap_coherent(vto);
>
> - if (vma->vm_flags & VM_EXEC)
> - flush_cache_page(vma, vaddr, page_to_pfn(page));
> + if (vma->vm_flags & VM_EXEC) {
> + extern void __flush_invalidate_region_icache(void *start, int size);
> + __flush_wback_region(vto, len);
> + __flush_invalidate_region_icache(vto, len);
> + }
> }
>
Two problems here, one is that you're trying to use vto outside of the
path where it's mapped (so the logic at least needs to be moved after the
memcpy() and before the kunmap_coherent(), and the other issue is that
this is precisely what flush_cache_page() is doing already. If
flush_cache_page() isn't working in this case, it's important to figure
out why that's so, rather than trying to side-step it with these
__flush_xxx() routines.
How does something like:
vto = ...
memcpy
if (vma->vm_flags & VM_EXEC)
flush_cache_page(vma, (unsigned long)vto, page_to_pfn(page));
kunmap_coherent(vto);
work?
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: needs writeback on ptrace
2008-02-15 0:52 needs writeback on ptrace Hideo Saito
2008-02-15 5:29 ` Paul Mundt
@ 2008-02-15 7:40 ` Hideo Saito
2008-02-15 7:56 ` Paul Mundt
2008-02-15 9:10 ` Hideo Saito
3 siblings, 0 replies; 5+ messages in thread
From: Hideo Saito @ 2008-02-15 7:40 UTC (permalink / raw)
To: linux-sh
On Fri, 15 Feb 2008 14:29:13 +0900, Paul Mundt wrote:
> Two problems here, one is that you're trying to use vto outside of the
> path where it's mapped (so the logic at least needs to be moved after the
> memcpy() and before the kunmap_coherent(), and the other issue is that
> this is precisely what flush_cache_page() is doing already. If
> flush_cache_page() isn't working in this case, it's important to figure
> out why that's so, rather than trying to side-step it with these
> __flush_xxx() routines.
>
> How does something like:
>
> vto = ...
> memcpy
>
> if (vma->vm_flags & VM_EXEC)
> flush_cache_page(vma, (unsigned long)vto, page_to_pfn(page));
>
> kunmap_coherent(vto);
>
> work?
The chang was not effective. If the following code at flush_cache_page() in cache-sh4.c is removed, gdb works.
if ((address^phys) & alias_mask) {
/* Loop 4K of the D-cache */
flush_cache_4096(
CACHE_OC_ADDRESS_ARRAY | (address & alias_mask),
phys);
/* Loop another 4K of the D-cache */
flush_cache_4096(
CACHE_OC_ADDRESS_ARRAY | (phys & alias_mask),
phys);
}
modified as follows:
if (1) {
...
}
I think that the breakpoint should always be written to the physical memory.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: needs writeback on ptrace
2008-02-15 0:52 needs writeback on ptrace Hideo Saito
2008-02-15 5:29 ` Paul Mundt
2008-02-15 7:40 ` Hideo Saito
@ 2008-02-15 7:56 ` Paul Mundt
2008-02-15 9:10 ` Hideo Saito
3 siblings, 0 replies; 5+ messages in thread
From: Paul Mundt @ 2008-02-15 7:56 UTC (permalink / raw)
To: linux-sh
On Fri, Feb 15, 2008 at 04:40:03PM +0900, Hideo Saito wrote:
> The chang was not effective. If the following code at
> flush_cache_page() in cache-sh4.c is removed, gdb works.
>
> if ((address^phys) & alias_mask) {
> /* Loop 4K of the D-cache */
> flush_cache_4096(
> CACHE_OC_ADDRESS_ARRAY | (address & alias_mask),
> phys);
> /* Loop another 4K of the D-cache */
> flush_cache_4096(
> CACHE_OC_ADDRESS_ARRAY | (phys & alias_mask),
> phys);
> }
>
> modified as follows:
> if (1) {
> ...
> }
>
> I think that the breakpoint should always be written to the physical memory.
What are the values of address, phys, and alias_mask on your platform in
this case?
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: needs writeback on ptrace
2008-02-15 0:52 needs writeback on ptrace Hideo Saito
` (2 preceding siblings ...)
2008-02-15 7:56 ` Paul Mundt
@ 2008-02-15 9:10 ` Hideo Saito
3 siblings, 0 replies; 5+ messages in thread
From: Hideo Saito @ 2008-02-15 9:10 UTC (permalink / raw)
To: linux-sh
On Fri, 15 Feb 2008 16:56:59 +0900, Paul Mundt wrote:
> What are the values of address, phys, and alias_mask on your platform in
> this case?
In the case of the condition |if ((address^phys) & alias_mask)| is not true, the values are as follows.
address@0678,phys×4a000,alias_mask\x1000
address@0678,phys×4a000,alias_mask\x1000
address)565040,physÐ45000,alias_mask\x1000
address)565040,physÐ45000,alias_mask\x1000
address@07e8,phys×4a000,alias_mask\x1000
address@07e8,phys×4a000,alias_mask\x1000
gdb steps following code
67 printf("n = %d, nn = %d, sum = %d\n", n, nn, nsum(n, nn));
(gdb) next
(gdb) info line 67
Line 67 of "hello.c" starts at address 0x4007d2 <main+366>
and ends at 0x400804 <main+416>.
(gdb) disas 0x4007d2 0x400804
Dump of assembler code from 0x4007d2 to 0x400804:
0x004007d2 <main+366>: mov r14,r1
0x004007d4 <main+368>: add #-16,r1
0x004007d6 <main+370>: mov.l @(24,r1),r2
0x004007d8 <main+372>: mov r14,r1
0x004007da <main+374>: add #-16,r1
0x004007dc <main+376>: mov.l @(28,r1),r1
0x004007de <main+378>: mov r2,r4
0x004007e0 <main+380>: mov r1,r5
0x004007e2 <main+382>: mov.l 0x4008cc <main+616>,r1 ! 0x40061a <nsum>
0x004007e4 <main+384>: jsr @r1
0x004007e6 <main+386>: nop
0x004007e8 <main+388>: mov.l 0x4008d0 <main+620>,r2 ! 0x400aac
0x004007ea <main+390>: mov r14,r1
0x004007ec <main+392>: add #-16,r1
0x004007ee <main+394>: mov.l @(24,r1),r3
0x004007f0 <main+396>: mov r14,r1
0x004007f2 <main+398>: add #-16,r1
0x004007f4 <main+400>: mov.l @(28,r1),r1
0x004007f6 <main+402>: mov r2,r4
0x004007f8 <main+404>: mov r3,r5
0x004007fa <main+406>: mov r1,r6
0x004007fc <main+408>: mov r0,r7
0x004007fe <main+410>: mov.l 0x4008d4 <main+624>,r1 ! 0x400360 <printf@plt>
0x00400800 <main+412>: jsr @r1
0x00400802 <main+414>: nop
End of assembler dump.
(gdb)
^ permalink raw reply [flat|nested] 5+ messages in thread