* Weird page fault while debugging an application using gdbserver
@ 2019-11-07 15:37 François Legal
2019-11-07 15:54 ` Philippe Gerum
0 siblings, 1 reply; 6+ messages in thread
From: François Legal @ 2019-11-07 15:37 UTC (permalink / raw)
To: xenomai
Hello,
I'm porting an existing application to xenomai, and trying to debug it using GDBserver.
I try to set a break to stop at some interesting point in execution. That break is never reached, and each time I get the page fault error with the log copied at the end of the message.
After that, I get the debug feature of the network driver automatically activated.
Starngely enought, the backtrace does not point to my application code, rather in linux kernel/drivers.
The system is an Arm7 Zynq 7000 reference board, being debugged via ethernet.
Running linux 4.4.189 vanilla + corresponding ipipe patch and xenomai 3.0.9
Anybody can help ?
Thanks
François
[ 5481.750121] Unhandled fault: page domain fault (0x01b) at 0x00033238
[ 5481.756485] pgd = 41eac000
[ 5481.759171] [00033238] *pgd=01c9e831, *pte=1f9105df, *ppte=1f910e7e
[ 5481.765435] Internal error: : 1b [#1] PREEMPT SMP ARM
[ 5481.770456] CPU: 0 PID: 745 Comm: Module de Confi Not tainted 4.4.189 #10
[ 5481.777217] Hardware name: Xilinx Zynq Platform
[ 5481.781729] I-pipe domain: Linux
[ 5481.784945] task: 5d892180 ti: 41ef6000 task.ti: 41ef6000
[ 5481.790333] PC is at __und_usr+0x68/0x80
[ 5481.794236] LR is at ipipe_unstall_root+0x30/0xa0
[ 5481.798921] pc : [<40015888>] lr : [<4009bdd4>] psr: 60000013
[ 5481.798921] sp : 41ef7fb0 ip : 41ef7e28 fp : 00000000
[ 5481.810377] r10: 000dd48c r9 : 40015a4c r8 : 18c5387d
[ 5481.815585] r7 : 18c5387d r6 : ffffffff r5 : 60000010 r4 : 00033238
[ 5481.822095] r3 : 60000010 r2 : 0003323c r1 : 00000000 r0 : 00000000
[ 5481.828606] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 5481.835723] Control: 18c5387d Table: 01eac04a DAC: 00000051
[ 5481.841451] Process Module de Confi (pid: 745, stack limit = 0x41ef6220)
[ 5481.848138] Stack: (0x41ef7fb0 to 0x41ef8000)
[ 5481.852480] 7fa0: 00000000 00000000 364884e4 00000000
[ 5481.860643] 7fc0: 00000000 36487e28 3efdebd4 000f0042 36487e2c 00032ea0 000dd48c 36487df4
[ 5481.868802] 7fe0: 36f206cc 36487d18 36f0711c 0003323c 60000010 ffffffff 00000000 00000000
[ 5481.876965] Code: f1080080 e3130020 1a000006 e2424004 (e4b40000)
[ 5481.883043] I-pipe tracer log (100 points):
[ 5481.887191] #func 0 ipipe_trace_panic_freeze+0x10 (oops_enter+0x1c)
[ 5481.895348] #func -2 oops_enter+0x10 (die+0x28)
[ 5481.901684] #func -2 die+0x14 (arm_notify_die+0x2c)
[ 5481.908368] #func -4 arm_notify_die+0x10 (do_DataAbort+0x11c)
[ 5481.915919] #func -5 wake_up_klogd+0x10 (console_unlock+0x338)
[ 5481.923558] #func -6 _raw_spin_unlock_irqrestore+0x10 (console_unlock+0x310)
[ 5481.932411] #func -7 __ipipe_spin_unlock_debug+0x10 (console_unlock+0x300)
[ 5481.941091] #func -8 _raw_spin_lock+0x10 (console_unlock+0x2e4)
[ 5481.948817] #func -8 _raw_spin_unlock_irqrestore+0x10 (up+0x50)
[ 5481.956543] #func -9 __ipipe_spin_unlock_debug+0x10 (up+0x44)
[ 5481.964093] #func -10 ipipe_root_only+0x10 (ipipe_test_and_stall_root+0x18)
[ 5481.972773] #func -11 ipipe_test_and_stall_root+0x10 (_raw_spin_lock_irqsave+0x1c)
[ 5481.982061] #func -12 _raw_spin_lock_irqsave+0x10 (up+0x1c)
[ 5481.989352] #func -13 up+0x10 (console_unlock+0x2d8)
[ 5481.996036] #func -13 _raw_spin_unlock+0x10 (console_unlock+0x2d0)
[ 5482.003935] #func -15 ipipe_root_only+0x10 (ipipe_test_and_stall_root+0x18)
[ 5482.012615] #func -16 ipipe_test_and_stall_root+0x10 (_raw_spin_lock_irqsave+0x1c)
[ 5482.021902] #func -16 _raw_spin_lock_irqsave+0x10 (console_unlock+0xd4)
[ 5482.030235] #func -17 _raw_spin_unlock_irqrestore+0x10 (cdns_uart_console_write+0x144)
[ 5482.039870] #func -18 __ipipe_spin_unlock_debug+0x10 (cdns_uart_console_write+0x138)
[ 5482.049331] #func -19 l2c210_sync+0x10 (arm_heavy_mb+0x2c)
[ 5482.056559] #func -20 arm_heavy_mb+0x10 (cdns_uart_console_write+0x118)
[ 5482.064868] #func -20 l2c210_sync+0x10 (arm_heavy_mb+0x2c)
[ 5482.072073] #func -21 arm_heavy_mb+0x10 (cdns_uart_console_write+0x104)
[ 5482.080446] #func -107 l2c210_sync+0x10 (arm_heavy_mb+0x2c)
[ 5482.087610] #func -108 arm_heavy_mb+0x10 (cdns_uart_console_putchar+0x3c)
[ 5482.096029] #func -144 cdns_uart_console_putchar+0x10 (uart_console_write+0x64)
[ 5482.104970] #func -144 l2c210_sync+0x10 (arm_heavy_mb+0x2c)
[ 5482.112174] #func -145 arm_heavy_mb+0x10 (cdns_uart_console_putchar+0x3c)
[ 5482.120595] #func -146 cdns_uart_console_putchar+0x10 (uart_console_write+0x58)
[ 5482.129534] #func -147 uart_console_write+0x10 (cdns_uart_console_write+0xcc)
[ 5482.138301] #func -148 l2c210_sync+0x10 (arm_heavy_mb+0x2c)
[ 5482.145506] #func -148 arm_heavy_mb+0x10 (cdns_uart_console_write+0xa4)
[ 5482.153751] #func -150 l2c210_sync+0x10 (arm_heavy_mb+0x2c)
[ 5482.160956] #func -150 arm_heavy_mb+0x10 (cdns_uart_console_write+0x8c)
[ 5482.169202] #func -152 ipipe_root_only+0x10 (ipipe_test_and_stall_root+0x18)
[ 5482.177882] #func -152 ipipe_test_and_stall_root+0x10 (_raw_spin_lock_irqsave+0x1c)
[ 5482.187169] #func -153 _raw_spin_lock_irqsave+0x10 (cdns_uart_console_write+0x15c)
[ 5482.196370] #func -154 cdns_uart_console_write+0x14 (call_console_drivers.constprop.13+0x110)
[ 5482.206526] #func -155 call_console_drivers.constprop.13+0x10 (console_unlock+0x288)
[ 5482.215901] #func -156 _raw_spin_unlock+0x10 (console_unlock+0x270)
[ 5482.223799] #func -157 ipipe_root_only+0x10 (ipipe_test_and_stall_root+0x18)
[ 5482.232479] #func -158 ipipe_test_and_stall_root+0x10 (_raw_spin_lock_irqsave+0x1c)
[ 5482.241767] #func -159 _raw_spin_lock_irqsave+0x10 (console_unlock+0x54)
[ 5482.250101] #func -159 console_unlock+0x14 (vprintk_emit+0x350)
[ 5482.257652] #func -160 _raw_spin_unlock_irqrestore+0x10 (down_trylock+0x3c)
[ 5482.266244] #func -161 __ipipe_spin_unlock_debug+0x10 (down_trylock+0x30)
[ 5482.274664] #func -162 ipipe_root_only+0x10 (ipipe_test_and_stall_root+0x18)
[ 5482.283344] #func -163 ipipe_test_and_stall_root+0x10 (_raw_spin_lock_irqsave+0x1c)
[ 5482.292631] #func -164 _raw_spin_lock_irqsave+0x10 (down_trylock+0x1c)
[ 5482.300791] #func -165 down_trylock+0x10 (console_trylock+0x1c)
[ 5482.308342] #func -165 console_trylock+0x10 (vprintk_emit+0x314)
[ 5482.315982] #func -166 _raw_spin_unlock+0x10 (vprintk_emit+0x2b4)
[ 5482.323706] #func -168 log_make_free_space+0x14 (log_store+0x50)
[ 5482.331344] #func -169 log_store+0x14 (cont_flush.part.2+0xb4)
[ 5482.338809] #func -170 cont_flush.part.2+0x14 (vprintk_emit+0x3f4)
[ 5482.346621] #func -171 cont_add+0x14 (vprintk_emit+0x3d0)
[ 5482.353660] #func -172 _raw_spin_lock+0x10 (vprintk_emit+0x184)
[ 5482.361213] #func -174 ipipe_root_only+0x10 (ipipe_test_and_stall_root+0x18)
[ 5482.369892] #func -174 ipipe_test_and_stall_root+0x10 (vprintk_emit+0x150)
[ 5482.378399] #func -175 vprintk_emit+0x14 (vprintk_default+0x34)
[ 5482.385950] #func -176 vprintk_default+0x14 (printk+0x1e0)
[ 5482.393068] #func -177 printk+0x18 (show_pte+0xe8)
[ 5482.399491] #func -179 _raw_spin_unlock_irqrestore+0x10 (console_unlock+0x310)
[ 5482.408345] #func -179 __ipipe_spin_unlock_debug+0x10 (console_unlock+0x300)
[ 5482.417025] #func -180 _raw_spin_lock+0x10 (console_unlock+0x2e4)
[ 5482.424750] #func -181 _raw_spin_unlock_irqrestore+0x10 (up+0x50)
[ 5482.432475] #func -182 __ipipe_spin_unlock_debug+0x10 (up+0x44)
[ 5482.440026] #func -183 ipipe_root_only+0x10 (ipipe_test_and_stall_root+0x18)
[ 5482.448707] #func -184 ipipe_test_and_stall_root+0x10 (_raw_spin_lock_irqsave+0x1c)
[ 5482.457995] #func -185 _raw_spin_lock_irqsave+0x10 (up+0x1c)
[ 5482.465285] #func -185 up+0x10 (console_unlock+0x2d8)
[ 5482.471969] #func -186 _raw_spin_unlock+0x10 (console_unlock+0x2d0)
[ 5482.479867] #func -188 ipipe_root_only+0x10 (ipipe_test_and_stall_root+0x18)
[ 5482.488548] #func -189 ipipe_test_and_stall_root+0x10 (_raw_spin_lock_irqsave+0x1c)
[ 5482.497836] #func -189 _raw_spin_lock_irqsave+0x10 (console_unlock+0xd4)
[ 5482.506168] #func -191 _raw_spin_unlock_irqrestore+0x10 (cdns_uart_console_write+0x144)
[ 5482.515803] #func -191 __ipipe_spin_unlock_debug+0x10 (cdns_uart_console_write+0x138)
[ 5482.525264] #func -192 l2c210_sync+0x10 (arm_heavy_mb+0x2c)
[ 5482.532469] #func -193 arm_heavy_mb+0x10 (cdns_uart_console_write+0x118)
[ 5482.540801] #func -194 l2c210_sync+0x10 (arm_heavy_mb+0x2c)
[ 5482.548006] #func -194 arm_heavy_mb+0x10 (cdns_uart_console_write+0x104)
[ 5482.556338] #func -280 l2c210_sync+0x10 (arm_heavy_mb+0x2c)
[ 5482.563543] #func -281 arm_heavy_mb+0x10 (cdns_uart_console_putchar+0x3c)
[ 5482.571963] #func -366 cdns_uart_console_putchar+0x10 (uart_console_write+0x38)
[ 5482.580903] #func -367 l2c210_sync+0x10 (arm_heavy_mb+0x2c)
[ 5482.588108] #func -368 arm_heavy_mb+0x10 (cdns_uart_console_putchar+0x3c)
[ 5482.596528] #func -453 cdns_uart_console_putchar+0x10 (uart_console_write+0x38)
[ 5482.605467] #func -454 l2c210_sync+0x10 (arm_heavy_mb+0x2c)
[ 5482.612672] #func -454 arm_heavy_mb+0x10 (cdns_uart_console_putchar+0x3c)
[ 5482.621091] #func -539 cdns_uart_console_putchar+0x10 (uart_console_write+0x38)
[ 5482.630032] #func -540 l2c210_sync+0x10 (arm_heavy_mb+0x2c)
[ 5482.637237] #func -541 arm_heavy_mb+0x10 (cdns_uart_console_putchar+0x3c)
[ 5482.645655] #func -545 cdns_uart_console_putchar+0x10 (uart_console_write+0x38)
[ 5482.654596] #func -546 l2c210_sync+0x10 (arm_heavy_mb+0x2c)
[ 5482.661802] #func -547 arm_heavy_mb+0x10 (cdns_uart_console_putchar+0x3c)
[ 5482.670220] | #func -548 __ipipe_bugon_irqs_enabled+0x10 (__ipipe_fast_svc_irq_exit+0x4)
[ 5482.679768] | #func -549 ipipe_test_root+0x10 (__ipipe_check_root_interruptible+0x5c)
[ 5482.689056] | #func -550 __ipipe_check_root_interruptible+0x10 (__irq_svc+0x58)
[ 5482.697824] | #func -551 __ipipe_do_sync_pipeline+0x14 (dispatch_irq_head+0x184)
[ 5482.706694] ---[ end trace b591dcdb6dbe58ba ]---
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Weird page fault while debugging an application using gdbserver
2019-11-07 15:37 Weird page fault while debugging an application using gdbserver François Legal
@ 2019-11-07 15:54 ` Philippe Gerum
2019-11-07 17:03 ` François Legal
0 siblings, 1 reply; 6+ messages in thread
From: Philippe Gerum @ 2019-11-07 15:54 UTC (permalink / raw)
To: François Legal, xenomai
On 2019-11-07 16:37, François Legal via Xenomai wrote:
> Hello,
>
> I'm porting an existing application to xenomai, and trying to debug it using GDBserver.
> I try to set a break to stop at some interesting point in execution. That break is never reached, and each time I get the page fault error with the log copied at the end of the message.
> After that, I get the debug feature of the network driver automatically activated.
>
> Starngely enought, the backtrace does not point to my application code, rather in linux kernel/drivers.
>
> The system is an Arm7 Zynq 7000 reference board, being debugged via ethernet.
> Running linux 4.4.189 vanilla + corresponding ipipe patch and xenomai 3.0.9
You likely need the following patch. This issue was fixed in the 4.14 time frame:
commit 8575e8ab404717e3eabafc36920459018bb052a3
Author: Philippe Gerum <rpm@xenomai.org>
Date: Tue Apr 10 11:34:29 2018 +0200
arm/ipipe: re-enable user access in DAC after und_user trap handling
Before returning from an und_user fault we have been asked to
propagate, the client trap handler might have demoted the caller from
the head -> root stage, which boils down to performing a (double)
context switch internally. If CONFIG_CPU_SW_DOMAIN_PAN is set, such
transition would cause the DAC register to reflect a protected USER
domain state, denying to the kernel access to user memory.
We need to revert this change, restoring the expected domain
protection settings originally set by usr_entry.
This fixes page domain errors raised by running into breakpoint traps
poked by GDB into the debuggee's executable image when
CONFIG_CPU_SW_DOMAIN_PAN is enabled in the kernel configuration.
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index cd2e0b3d8336..3569b3174372 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -524,6 +524,7 @@ __und_usr:
bl __ipipe_notify_trap @ branch to trap handler
cmp r0, #0
bne ret_from_exception
+ uaccess_enable ip
#endif /* CONFIG_IPIPE */
mov r2, r4
--
Philippe.
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: Weird page fault while debugging an application using gdbserver
2019-11-07 15:54 ` Philippe Gerum
@ 2019-11-07 17:03 ` François Legal
2019-11-08 9:05 ` Philippe Gerum
0 siblings, 1 reply; 6+ messages in thread
From: François Legal @ 2019-11-07 17:03 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
Le Jeudi, Novembre 07, 2019 16:54 CET, Philippe Gerum <rpm@xenomai.org> a écrit:
> On 2019-11-07 16:37, François Legal via Xenomai wrote:
> > Hello,
> >
> > I'm porting an existing application to xenomai, and trying to debug it using GDBserver.
> > I try to set a break to stop at some interesting point in execution. That break is never reached, and each time I get the page fault error with the log copied at the end of the message.
> > After that, I get the debug feature of the network driver automatically activated.
> >
> > Starngely enought, the backtrace does not point to my application code, rather in linux kernel/drivers.
> >
> > The system is an Arm7 Zynq 7000 reference board, being debugged via ethernet.
> > Running linux 4.4.189 vanilla + corresponding ipipe patch and xenomai 3.0.9
>
> You likely need the following patch. This issue was fixed in the 4.14 time frame:
>
> commit 8575e8ab404717e3eabafc36920459018bb052a3
> Author: Philippe Gerum <rpm@xenomai.org>
> Date: Tue Apr 10 11:34:29 2018 +0200
>
> arm/ipipe: re-enable user access in DAC after und_user trap handling
>
> Before returning from an und_user fault we have been asked to
> propagate, the client trap handler might have demoted the caller from
> the head -> root stage, which boils down to performing a (double)
> context switch internally. If CONFIG_CPU_SW_DOMAIN_PAN is set, such
> transition would cause the DAC register to reflect a protected USER
> domain state, denying to the kernel access to user memory.
>
> We need to revert this change, restoring the expected domain
> protection settings originally set by usr_entry.
>
> This fixes page domain errors raised by running into breakpoint traps
> poked by GDB into the debuggee's executable image when
> CONFIG_CPU_SW_DOMAIN_PAN is enabled in the kernel configuration.
>
> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> index cd2e0b3d8336..3569b3174372 100644
> --- a/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -524,6 +524,7 @@ __und_usr:
> bl __ipipe_notify_trap @ branch to trap handler
> cmp r0, #0
> bne ret_from_exception
> + uaccess_enable ip
> #endif /* CONFIG_IPIPE */
>
> mov r2, r4
>
> --
> Philippe.
Thanks. I do not get the page fault anymore, however, I seem to be unable to halt on breakpoints now.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Weird page fault while debugging an application using gdbserver
2019-11-07 17:03 ` François Legal
@ 2019-11-08 9:05 ` Philippe Gerum
2019-11-08 9:22 ` Jan Kiszka
0 siblings, 1 reply; 6+ messages in thread
From: Philippe Gerum @ 2019-11-08 9:05 UTC (permalink / raw)
To: François Legal; +Cc: xenomai
On 2019-11-07 18:03, François Legal wrote:
> Le Jeudi, Novembre 07, 2019 16:54 CET, Philippe Gerum <rpm@xenomai.org> a écrit:
>
>> On 2019-11-07 16:37, François Legal via Xenomai wrote:
>>> Hello,
>>>
>>> I'm porting an existing application to xenomai, and trying to debug it using GDBserver.
>>> I try to set a break to stop at some interesting point in execution. That break is never reached, and each time I get the page fault error with the log copied at the end of the message.
>>> After that, I get the debug feature of the network driver automatically activated.
>>>
>>> Starngely enought, the backtrace does not point to my application code, rather in linux kernel/drivers.
>>>
>>> The system is an Arm7 Zynq 7000 reference board, being debugged via ethernet.
>>> Running linux 4.4.189 vanilla + corresponding ipipe patch and xenomai 3.0.9
>>
>> You likely need the following patch. This issue was fixed in the 4.14 time frame:
>>
>> commit 8575e8ab404717e3eabafc36920459018bb052a3
>> Author: Philippe Gerum <rpm@xenomai.org>
>> Date: Tue Apr 10 11:34:29 2018 +0200
>>
>> arm/ipipe: re-enable user access in DAC after und_user trap handling
>>
>> Before returning from an und_user fault we have been asked to
>> propagate, the client trap handler might have demoted the caller from
>> the head -> root stage, which boils down to performing a (double)
>> context switch internally. If CONFIG_CPU_SW_DOMAIN_PAN is set, such
>> transition would cause the DAC register to reflect a protected USER
>> domain state, denying to the kernel access to user memory.
>>
>> We need to revert this change, restoring the expected domain
>> protection settings originally set by usr_entry.
>>
>> This fixes page domain errors raised by running into breakpoint traps
>> poked by GDB into the debuggee's executable image when
>> CONFIG_CPU_SW_DOMAIN_PAN is enabled in the kernel configuration.
>>
>> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
>> index cd2e0b3d8336..3569b3174372 100644
>> --- a/arch/arm/kernel/entry-armv.S
>> +++ b/arch/arm/kernel/entry-armv.S
>> @@ -524,6 +524,7 @@ __und_usr:
>> bl __ipipe_notify_trap @ branch to trap handler
>> cmp r0, #0
>> bne ret_from_exception
>> + uaccess_enable ip
>> #endif /* CONFIG_IPIPE */
>>
>> mov r2, r4
>>
>> --
>> Philippe.
>
> Thanks. I do not get the page fault anymore, however, I seem to be unable to halt on breakpoints now.
>
Just checked with 4.4.176-arm-10 + this patch, no issue setting and taking a breakpoint in a simple demo program using gdb directly. You may want to check if gdbserver is not involved in the remaining issue. At any rate, the change proposed would not prevent the debug exception to be taken (on the contrary, actually).
--
Philippe.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Weird page fault while debugging an application using gdbserver
2019-11-08 9:05 ` Philippe Gerum
@ 2019-11-08 9:22 ` Jan Kiszka
2019-11-12 10:52 ` Philippe Gerum
0 siblings, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2019-11-08 9:22 UTC (permalink / raw)
To: Philippe Gerum, François Legal; +Cc: xenomai
On 08.11.19 10:05, Philippe Gerum via Xenomai wrote:
> On 2019-11-07 18:03, François Legal wrote:
>> Le Jeudi, Novembre 07, 2019 16:54 CET, Philippe Gerum <rpm@xenomai.org> a écrit:
>>
>>> On 2019-11-07 16:37, François Legal via Xenomai wrote:
>>>> Hello,
>>>>
>>>> I'm porting an existing application to xenomai, and trying to debug it using GDBserver.
>>>> I try to set a break to stop at some interesting point in execution. That break is never reached, and each time I get the page fault error with the log copied at the end of the message.
>>>> After that, I get the debug feature of the network driver automatically activated.
>>>>
>>>> Starngely enought, the backtrace does not point to my application code, rather in linux kernel/drivers.
>>>>
>>>> The system is an Arm7 Zynq 7000 reference board, being debugged via ethernet.
>>>> Running linux 4.4.189 vanilla + corresponding ipipe patch and xenomai 3.0.9
>>>
>>> You likely need the following patch. This issue was fixed in the 4.14 time frame:
>>>
>>> commit 8575e8ab404717e3eabafc36920459018bb052a3
>>> Author: Philippe Gerum <rpm@xenomai.org>
>>> Date: Tue Apr 10 11:34:29 2018 +0200
>>>
>>> arm/ipipe: re-enable user access in DAC after und_user trap handling
>>>
>>> Before returning from an und_user fault we have been asked to
>>> propagate, the client trap handler might have demoted the caller from
>>> the head -> root stage, which boils down to performing a (double)
>>> context switch internally. If CONFIG_CPU_SW_DOMAIN_PAN is set, such
>>> transition would cause the DAC register to reflect a protected USER
>>> domain state, denying to the kernel access to user memory.
>>>
>>> We need to revert this change, restoring the expected domain
>>> protection settings originally set by usr_entry.
>>>
>>> This fixes page domain errors raised by running into breakpoint traps
>>> poked by GDB into the debuggee's executable image when
>>> CONFIG_CPU_SW_DOMAIN_PAN is enabled in the kernel configuration.
>>>
>>> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
>>> index cd2e0b3d8336..3569b3174372 100644
>>> --- a/arch/arm/kernel/entry-armv.S
>>> +++ b/arch/arm/kernel/entry-armv.S
>>> @@ -524,6 +524,7 @@ __und_usr:
>>> bl __ipipe_notify_trap @ branch to trap handler
>>> cmp r0, #0
>>> bne ret_from_exception
>>> + uaccess_enable ip
>>> #endif /* CONFIG_IPIPE */
>>>
>>> mov r2, r4
>>>
>>> --
>>> Philippe.
>>
>> Thanks. I do not get the page fault anymore, however, I seem to be unable to halt on breakpoints now.
>>
>
> Just checked with 4.4.176-arm-10 + this patch, no issue setting and taking a breakpoint in a simple demo program using gdb directly. You may want to check if gdbserver is not involved in the remaining issue. At any rate, the change proposed would not prevent the debug exception to be taken (on the contrary, actually).
>
I guess that patch would nice to have in ipipe-4.4.y-cip as well. Is
there more to pick from new kernels?
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Weird page fault while debugging an application using gdbserver
2019-11-08 9:22 ` Jan Kiszka
@ 2019-11-12 10:52 ` Philippe Gerum
0 siblings, 0 replies; 6+ messages in thread
From: Philippe Gerum @ 2019-11-12 10:52 UTC (permalink / raw)
To: Jan Kiszka, François Legal; +Cc: xenomai
On 11/8/19 10:22 AM, Jan Kiszka wrote:
> On 08.11.19 10:05, Philippe Gerum via Xenomai wrote:
>> On 2019-11-07 18:03, François Legal wrote:
>>> Le Jeudi, Novembre 07, 2019 16:54 CET, Philippe Gerum <rpm@xenomai.org> a écrit:
>>>
>>>> On 2019-11-07 16:37, François Legal via Xenomai wrote:
>>>>> Hello,
>>>>>
>>>>> I'm porting an existing application to xenomai, and trying to debug it using GDBserver.
>>>>> I try to set a break to stop at some interesting point in execution. That break is never reached, and each time I get the page fault error with the log copied at the end of the message.
>>>>> After that, I get the debug feature of the network driver automatically activated.
>>>>>
>>>>> Starngely enought, the backtrace does not point to my application code, rather in linux kernel/drivers.
>>>>>
>>>>> The system is an Arm7 Zynq 7000 reference board, being debugged via ethernet.
>>>>> Running linux 4.4.189 vanilla + corresponding ipipe patch and xenomai 3.0.9
>>>>
>>>> You likely need the following patch. This issue was fixed in the 4.14 time frame:
>>>>
>>>> commit 8575e8ab404717e3eabafc36920459018bb052a3
>>>> Author: Philippe Gerum <rpm@xenomai.org>
>>>> Date: Tue Apr 10 11:34:29 2018 +0200
>>>>
>>>> arm/ipipe: re-enable user access in DAC after und_user trap handling
>>>> Before returning from an und_user fault we have been asked to
>>>> propagate, the client trap handler might have demoted the caller from
>>>> the head -> root stage, which boils down to performing a (double)
>>>> context switch internally. If CONFIG_CPU_SW_DOMAIN_PAN is set, such
>>>> transition would cause the DAC register to reflect a protected USER
>>>> domain state, denying to the kernel access to user memory.
>>>> We need to revert this change, restoring the expected domain
>>>> protection settings originally set by usr_entry.
>>>> This fixes page domain errors raised by running into breakpoint traps
>>>> poked by GDB into the debuggee's executable image when
>>>> CONFIG_CPU_SW_DOMAIN_PAN is enabled in the kernel configuration.
>>>>
>>>> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
>>>> index cd2e0b3d8336..3569b3174372 100644
>>>> --- a/arch/arm/kernel/entry-armv.S
>>>> +++ b/arch/arm/kernel/entry-armv.S
>>>> @@ -524,6 +524,7 @@ __und_usr:
>>>> bl __ipipe_notify_trap @ branch to trap handler
>>>> cmp r0, #0
>>>> bne ret_from_exception
>>>> + uaccess_enable ip
>>>> #endif /* CONFIG_IPIPE */
>>>> mov r2, r4
>>>>
>>>> --
>>>> Philippe.
>>> Thanks. I do not get the page fault anymore, however, I seem to be unable to halt on breakpoints now.
>>>
>>
>> Just checked with 4.4.176-arm-10 + this patch, no issue setting and taking a breakpoint in a simple demo program using gdb directly. You may want to check if gdbserver is not involved in the remaining issue. At any rate, the change proposed would not prevent the debug exception to be taken (on the contrary, actually).
>>
>
> I guess that patch would nice to have in ipipe-4.4.y-cip as well. Is there more to pick from new kernels?
>
For 4.4, I would pick these:
https://gitlab.denx.de/Xenomai/ipipe-arm/commit/8575e8ab404717e3eabafc36920459018bb052a3
https://gitlab.denx.de/Xenomai/ipipe-arm/commit/b3a7fed2583a06ba5d7165600be111a16c124924
https://gitlab.denx.de/Xenomai/ipipe-arm/commit/73eac667cd79e1f395deaeff634ddff7060176b5
--
Philippe.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-11-12 10:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-07 15:37 Weird page fault while debugging an application using gdbserver François Legal
2019-11-07 15:54 ` Philippe Gerum
2019-11-07 17:03 ` François Legal
2019-11-08 9:05 ` Philippe Gerum
2019-11-08 9:22 ` Jan Kiszka
2019-11-12 10:52 ` Philippe Gerum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.