Re: Again: UML on s390 (31Bit)

From: Bodo Stroesser (bstroesser_at_fujitsu-siemens.com)
Date: 04/29/05

  • Next message: Christoph Pleger: "Serial Mouse in Kernel 2.6" 
    Date:	Fri, 29 Apr 2005 14:47:51 +0200
To: Martin Schwidefsky <schwidefsky@de.ibm.com>

    Martin Schwidefsky wrote:
    > Yes, it is not a really good idea to add something to struct user. That will
    > affect the dump format and debugging tools. So it would be an additional ptrace
    > command like PTRACE_SETTRAP/PTRACE_GETTRAP. The only other solution I can think
    > of is to be more specific about what the debugger can indicate to the debuggee
    > what needs to be done after the first syscall_trace invocation. At the moment
    > it is either
    > 1) a valid system call number, execute the new syscall, or
    > 2) an invalid system call number, skip the system call but don't change
    > regs->traps and do system call restarting if another signal is pending
    > If we use more specific error codes instead of just any invalid syscall number
    > we could have e.g. this:
    > 1) a vaild system call number, execute the new syscall,
    > 2) -Exxx, skip the system call, store -1 to regs->trap and then continue
    > with restarting system calls if another system call is pending.
    Typo with<->without?

    Yes. That's what I suggested as a "special magic number". Only if that magic
    is written as syscall number at the first interception, syscall_trace() would
    modify regs->trap to -1.
    Currently my patch uses -1 as the magic number, but there might be better
    choices.

    > 3) -Eyyy, skip the system call but leave regs->trap intact so that a pending
    > signal will restart the system call.
    Not only -Eyyy, but all values unequal to "special magic number" could leave
    regs->trap intact.

    >
    > But we really have to be very careful not to break either strace or gdb if
    > we do this change. Probably it is much easier to introduce PTRACE_SET/GET_TRAP.
    It's easier for s390-kernel, but from UML's point of view, the magic number
    solution would be better.
    Anyway, if you decide not to allow the magic number, we have to find a way
    to use PTRACE_SETTRAP in UML without having to call it too often (Performance).
    Because of UML's splitting in kernel-obj and user-obj, this might be a bit
    tricky.

    BTW: I see no reason to implement PTRACE_GETTRAP, as
    PTRACE_SETOPTIONS/PTRACE_TRACESYSGOOD give us a way to distinguish between
    syscall interceptions and other SIGTRAPs.

    Regards, Bodo
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Christoph Pleger: "Serial Mouse in Kernel 2.6"

    Relevant Pages