[OpenRISC] trap exception handling in linux kernel

[OpenRISC] trap exception handling in linux kernel

[Vad Rulezz]

Hello

In arch/openrisc/kernel/traps.c we have a function:

asmlinkage void do_trap(struct pt_regs *regs, unsigned long address)
{
	force_sig_fault(SIGTRAP, TRAP_TRACE, (void __user *)address, current);

	regs->pc += 4;
}

Is there a reason for regs->pc increment?

I think typically debuggers wants to resume program execution from the same address which caused a trap (after disabling a breakpoint, and it's a sw breakpoint after replacing an instruction at this address).



Vad Rulezz

[OpenRISC] trap exception handling in linux kernel

[Stafford Horne]

Hello,

Did you ever get a response for this?  I believe this is to allow
jumping over the openrisc l.trap instruction.  But, as you say
GDB/debuggers will replace that instruction with the real instruction,
so it shouldn't be needed.

Have you noticed an issue or are you just auditing this?   We don't
usually run GDB from within openrisc linux, I haven't run into this
issue before.

-Stafford

On Mon, Jan 7, 2019 at 3:07 AM Vad Rulezz <vad@vr5.epicgamer.org> wrote:
>
> Hello
>
> In arch/openrisc/kernel/traps.c we have a function:
>
> asmlinkage void do_trap(struct pt_regs *regs, unsigned long address)
> {
>         force_sig_fault(SIGTRAP, TRAP_TRACE, (void __user *)address, current);
>
>         regs->pc += 4;
> }
>
> Is there a reason for regs->pc increment?
>
> I think typically debuggers wants to resume program execution from the same address which caused a trap (after disabling a breakpoint, and it's a sw breakpoint after replacing an instruction at this address).
>
>
>
> Vad Rulezz
> _______________________________________________
> OpenRISC mailing list
> OpenRISC at lists.librecores.org
> https://lists.librecores.org/listinfo/openrisc

[OpenRISC] trap exception handling in linux kernel

[Vad Rulezz]

I have actually discovered it in a native debugger, ofc it was not hard to remove the line in my copy of kernel and everything ran well after that,
but I still decided to ask because I thought that maybe there is a software that depends on existing behavior.

As noone except you replied I think it's safe to remove the increment in the mainline. It likely will simplify things for native GDB too.


Vad Rulezz

On 03.03.2019 18:29, Stafford Horne wrote:
> Did you ever get a response for this?  I believe this is to allow
> jumping over the openrisc l.trap instruction.  But, as you say
> GDB/debuggers will replace that instruction with the real instruction,
> so it shouldn't be needed.
> 
> Have you noticed an issue or are you just auditing this?   We don't
> usually run GDB from within openrisc linux, I haven't run into this
> issue before.
> 
> -Stafford
> 
> On Mon, Jan 7, 2019 at 3:07 AM Vad Rulezz <vad@vr5.epicgamer.org> wrote:
>>
>> Hello
>>
>> In arch/openrisc/kernel/traps.c we have a function:
>>
>> asmlinkage void do_trap(struct pt_regs *regs, unsigned long address)
>> {
>>         force_sig_fault(SIGTRAP, TRAP_TRACE, (void __user *)address, current);
>>
>>         regs->pc += 4;
>> }
>>
>> Is there a reason for regs->pc increment?
>>
>> I think typically debuggers wants to resume program execution from the same address which caused a trap (after disabling a breakpoint, and it's a sw breakpoint after replacing an instruction at this address).
>>
>>
>>
>> Vad Rulezz
>> _______________________________________________
>> OpenRISC mailing list
>> OpenRISC at lists.librecores.org
>> https://lists.librecores.org/listinfo/openrisc
> 

[OpenRISC] trap exception handling in linux kernel

[Stafford Horne]

Hello,

That sounds good. I'll create a patch.

Btw were you using my gdb Linux support patches?

-Stafford

On Mon, Mar 4, 2019, 4:38 AM Vad Rulezz <vad@vr5.epicgamer.org> wrote:

> I have actually discovered it in a native debugger, ofc it was not hard to
> remove the line in my copy of kernel and everything ran well after that,
> but I still decided to ask because I thought that maybe there is a
> software that depends on existing behavior.
>
> As noone except you replied I think it's safe to remove the increment in
> the mainline. It likely will simplify things for native GDB too.
>
>
> Vad Rulezz
>
> On 03.03.2019 18:29, Stafford Horne wrote:
> > Did you ever get a response for this?  I believe this is to allow
> > jumping over the openrisc l.trap instruction.  But, as you say
> > GDB/debuggers will replace that instruction with the real instruction,
> > so it shouldn't be needed.
> >
> > Have you noticed an issue or are you just auditing this?   We don't
> > usually run GDB from within openrisc linux, I haven't run into this
> > issue before.
> >
> > -Stafford
> >
> > On Mon, Jan 7, 2019 at 3:07 AM Vad Rulezz <vad@vr5.epicgamer.org> wrote:
> >>
> >> Hello
> >>
> >> In arch/openrisc/kernel/traps.c we have a function:
> >>
> >> asmlinkage void do_trap(struct pt_regs *regs, unsigned long address)
> >> {
> >>         force_sig_fault(SIGTRAP, TRAP_TRACE, (void __user *)address,
> current);
> >>
> >>         regs->pc += 4;
> >> }
> >>
> >> Is there a reason for regs->pc increment?
> >>
> >> I think typically debuggers wants to resume program execution from the
> same address which caused a trap (after disabling a breakpoint, and it's a
> sw breakpoint after replacing an instruction at this address).
> >>
> >>
> >>
> >> Vad Rulezz
> >> _______________________________________________
> >> OpenRISC mailing list
> >> OpenRISC at lists.librecores.org
> >> https://lists.librecores.org/listinfo/openrisc
> >
>
> _______________________________________________
> OpenRISC mailing list
> OpenRISC at lists.librecores.org
> https://lists.librecores.org/listinfo/openrisc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20190304/e12cca70/attachment.html>

[OpenRISC] trap exception handling in linux kernel

[Vad Rulezz]

> Btw were you using my gdb Linux support patches?

Actually no.
But maybe I'll give them a try.


Vad Rulezz

On 04.03.2019 02:10, Stafford Horne wrote:
> Hello, 
> 
> That sounds good. I'll create a patch.
> 
> Btw were you using my gdb Linux support patches?
> 
> -Stafford
> 
> On Mon, Mar 4, 2019, 4:38 AM Vad Rulezz <vad at vr5.epicgamer.org <mailto:vad@vr5.epicgamer.org>> wrote:
> 
>     I have actually discovered it in a native debugger, ofc it was not hard to remove the line in my copy of kernel and everything ran well after that,
>     but I still decided to ask because I thought that maybe there is a software that depends on existing behavior.
> 
>     As noone except you replied I think it's safe to remove the increment in the mainline. It likely will simplify things for native GDB too.
> 
> 
>     Vad Rulezz
> 
>     On 03.03.2019 18:29, Stafford Horne wrote:
>     > Did you ever get a response for this?  I believe this is to allow
>     > jumping over the openrisc l.trap instruction.  But, as you say
>     > GDB/debuggers will replace that instruction with the real instruction,
>     > so it shouldn't be needed.
>     >
>     > Have you noticed an issue or are you just auditing this?   We don't
>     > usually run GDB from within openrisc linux, I haven't run into this
>     > issue before.
>     >
>     > -Stafford
>     >
>     > On Mon, Jan 7, 2019 at 3:07 AM Vad Rulezz <vad at vr5.epicgamer.org <mailto:vad@vr5.epicgamer.org>> wrote:
>     >>
>     >> Hello
>     >>
>     >> In arch/openrisc/kernel/traps.c we have a function:
>     >>
>     >> asmlinkage void do_trap(struct pt_regs *regs, unsigned long address)
>     >> {
>     >>         force_sig_fault(SIGTRAP, TRAP_TRACE, (void __user *)address, current);
>     >>
>     >>         regs->pc += 4;
>     >> }
>     >>
>     >> Is there a reason for regs->pc increment?
>     >>
>     >> I think typically debuggers wants to resume program execution from the same address which caused a trap (after disabling a breakpoint, and it's a sw breakpoint after replacing an instruction at this address).
>     >>
>     >>
>     >>
>     >> Vad Rulezz
>     >> _______________________________________________
>     >> OpenRISC mailing list
>     >> OpenRISC at lists.librecores.org <mailto:OpenRISC@lists.librecores.org>
>     >> https://lists.librecores.org/listinfo/openrisc
>     >
> 
>     _______________________________________________
>     OpenRISC mailing list
>     OpenRISC at lists.librecores.org <mailto:OpenRISC@lists.librecores.org>
>     https://lists.librecores.org/listinfo/openrisc
>