Re: utrace-ptrace gdb testsuite tesults
Followed the differences found by Qian and verified none of them (did not verify the ppc suspicious one) has any regression in GDB testsuite. I did not reproduce the original possible regression seen on ppc64 RHEL6 systems. The kernel was build directly from roland's git tree with and without CONFIG_UTRACE. $ diff -u noutrace/gdb-64.sum utrace/gdb-64.sum --- noutrace/gdb-64.sum 2009-11-30 16:29:16.793769391 +0800 +++ utrace/gdb-64.sum 2009-11-30 16:28:06.249892712 +0800 @@ -1,4 +1,4 @@ -Test Run By root on Mon Nov 30 02:27:53 2009 +Test Run By root on Mon Nov 30 02:27:59 2009 Native configuration is powerpc64-unknown-linux-gnu === gdb tests === @@ -4046,7 +4046,7 @@ PASS: gdb.base/foll-fork.exp: default parent follow, no catchpoints PASS: gdb.base/foll-fork.exp: set follow parent PASS: gdb.base/foll-fork.exp: explicit show parent follow, no catchpoints -PASS: gdb.base/foll-fork.exp: explicit parent follow, no catchpoints +FAIL: gdb.base/foll-fork.exp: (timeout) explicit parent follow, no catchpoints PASS: gdb.base/foll-fork.exp: set follow child PASS: gdb.base/foll-fork.exp: explicit show child follow, no catchpoints PASS: gdb.base/foll-fork.exp: explicit child follow, no catchpoints @@ -14764,7 +14764,7 @@ PASS: gdb.threads/attach-stopped.exp: threaded: set file, before attach1 to stopped process (re-read) PASS: gdb.threads/attach-stopped.exp: threaded: attach1 to stopped, after setting file PASS: gdb.threads/attach-stopped.exp: threaded: attach1 to stopped bt -FAIL: gdb.threads/attach-stopped.exp: threaded: attach1, exit leaves process stopped +PASS: gdb.threads/attach-stopped.exp: threaded: attach1, exit leaves process stopped PASS: gdb.threads/attach-stopped.exp: threaded: attach2 to stopped, after setting file PASS: gdb.threads/attach-stopped.exp: threaded: attach2 to stopped bt PASS: gdb.threads/attach-stopped.exp: continue (threaded: attach2 continue) I'll try to schedule it on a few other ppc64 systems to see if make any difference. CAI Qian
Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.
On Mon, 2009-11-30 at 17:33 +0530, Srikar Dronamraju wrote: This patch implements an in-kernel gdb stub. It provides an interface between gdb and Linux Kernel by implementing the remote serial protocol. This gdbstub uses utrace infrastructure. This patch provides register set access, signal mapping, process event handling, input/output operations. /proc/pid/gdb was chosen as file for gdb to interact with the process through remote serial protocol. Hence users would have to use target remote /proc/pid/gdb command on gdb prompt to start using this infrastructure. For Breakpointing support, gdbstub needs User space breakpointing layer and uprobes layer which will be posted later. How does this compare to kgdb and related efforts?
Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.
* Peter Zijlstra pet...@infradead.org [2009-11-30 13:09:12]: On Mon, 2009-11-30 at 17:33 +0530, Srikar Dronamraju wrote: This patch implements an in-kernel gdb stub. It provides an interface between gdb and Linux Kernel by implementing the remote serial protocol. This gdbstub uses utrace infrastructure. This patch provides register set access, signal mapping, process event handling, input/output operations. /proc/pid/gdb was chosen as file for gdb to interact with the process through remote serial protocol. Hence users would have to use target remote /proc/pid/gdb command on gdb prompt to start using this infrastructure. For Breakpointing support, gdbstub needs User space breakpointing layer and uprobes layer which will be posted later. How does this compare to kgdb and related efforts? This is a In-kernel gdbstub to debug user space programs. This stub doesnt help in debugging kernel. Hence I am not sure how to compare kgdb gdbstub with this gdbstub. Can you please provide more pointers on what you were referring to? -- Thanks and Regards Srikar
Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.
On Mon, 2009-11-30 at 18:02 +0530, Srikar Dronamraju wrote: * Peter Zijlstra pet...@infradead.org [2009-11-30 13:09:12]: On Mon, 2009-11-30 at 17:33 +0530, Srikar Dronamraju wrote: This patch implements an in-kernel gdb stub. It provides an interface between gdb and Linux Kernel by implementing the remote serial protocol. This gdbstub uses utrace infrastructure. This patch provides register set access, signal mapping, process event handling, input/output operations. /proc/pid/gdb was chosen as file for gdb to interact with the process through remote serial protocol. Hence users would have to use target remote /proc/pid/gdb command on gdb prompt to start using this infrastructure. For Breakpointing support, gdbstub needs User space breakpointing layer and uprobes layer which will be posted later. How does this compare to kgdb and related efforts? This is a In-kernel gdbstub to debug user space programs. This stub doesnt help in debugging kernel. Hence I am not sure how to compare kgdb gdbstub with this gdbstub. Can you please provide more pointers on what you were referring to? Well, not even that much was clear from your changelog, so I wasn't really sure wtf I was looking at. All it says was an in-kernel gdb stub, what other than to debug the kernel would you need in-kernel stubs for? So now my question is, what do you need an in-kernel stub to debug userspace for? In general, tell me about this patch thing, what does it do, why does it do it, and how does it improve on the current situation. Your changelog doesn't address any of those things, so wth are we supposed to think?
Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.
* Peter Zijlstra pet...@infradead.org [2009-11-30 13:41:47]: This is a In-kernel gdbstub to debug user space programs. This stub doesnt help in debugging kernel. Hence I am not sure how to compare kgdb gdbstub with this gdbstub. Can you please provide more pointers on what you were referring to? Well, not even that much was clear from your changelog, so I wasn't really sure wtf I was looking at. All it says was an in-kernel gdb stub, what other than to debug the kernel would you need in-kernel stubs for? So now my question is, what do you need an in-kernel stub to debug userspace for? This stub would allow users use features provided by utrace but through a gdb interface. This idea was brought up in this year's Tracing roundtable at the Linux Foundation Collaboration summit, April 8-10 in San Francisco. Here is the link to the minutes of the meeting sent by Christoph Hellwig. http://www.mail-archive.com/utrace-devel@redhat.com/msg00830.html In general, tell me about this patch thing, what does it do, why does it do it, and how does it improve on the current situation. This is suppose to be one of the interfaces to use utrace, i.e Allow gdb to use utrace features without having to change gdb itself. Though there are not enough features in this patch, intentions include support multi-threaded debugging, concurrent debugger support for same process, syscall tracing. For Breakpoint support(not yet submitted to LKML), it would use execution out of line rather than the conventional inline-single stepping. I guess Christoph, Roland and Frank would be able to explain in a better fashion the rational and advantages of this stub over convential gdb. Your changelog doesn't address any of those things, so wth are we supposed to think? Thanks for pointing out. -- Thanks and Regards Srikar
Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.
On Mon, 2009-11-30 at 18:49 +0530, Srikar Dronamraju wrote: This is suppose to be one of the interfaces to use utrace, i.e Allow gdb to use utrace features without having to change gdb itself. Though there are not enough features in this patch, intentions include support multi-threaded debugging, concurrent debugger support for same process, syscall tracing. For Breakpoint support(not yet submitted to LKML), it would use execution out of line rather than the conventional inline-single stepping. I guess Christoph, Roland and Frank would be able to explain in a better fashion the rational and advantages of this stub over convential gdb. Hmm,. wouldn't it make much more sense to extend the current kgdb stub to include userspace debugging, providing an all-in-one solution? I think it would be much more powerful to be able to observe the full software stack and not be limited by this user-kernel barrier. (Provided the user has sufficient privileges of course).
Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.
I guess Christoph, Roland and Frank would be able to explain in a better fashion the rational and advantages of this stub over convential gdb. Hmm,. wouldn't it make much more sense to extend the current kgdb stub to include userspace debugging, providing an all-in-one solution? I see two limitations but I guess there could be ways to get over it. 1. gdb requiring file that needs to be debugged. I always thought it can either be a user program or a vmlinux file. gdb makes most of the information(i.e registers) from the remote protocol to display the backtrace, variable values and the like by reading this file. 2. Also I am not sure if gdb has a way to tell the remote to switch the context and provide information(registers) pertaining to the user mode/ kernel mode. There could be other limitations too that I may not be aware. I think it would be much more powerful to be able to observe the full software stack and not be limited by this user-kernel barrier. (Provided the user has sufficient privileges of course). In this implementation, the current user can debug his/her own processes. May be if we can debug both the context from same gdb then we might have to place restrictions.. -- Thanks and Regards Srikar
Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.
peterz wrote: Hmm,. wouldn't it make much more sense to extend the current kgdb stub to include userspace debugging, providing an all-in-one solution? I think it would be much more powerful to be able to observe the full software stack and not be limited by this user-kernel barrier. There exist other tools for this broad a scope (systemtap being one), and present gdb is not well suited for this. That makes this idea an exciting potential for the future, but not a practical short-term goal. - FChE
Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.
* Frank Ch. Eigler f...@redhat.com wrote: peterz wrote: Hmm,. wouldn't it make much more sense to extend the current kgdb stub to include userspace debugging, providing an all-in-one solution? I think it would be much more powerful to be able to observe the full software stack and not be limited by this user-kernel barrier. There exist other tools for this broad a scope (systemtap being one), and present gdb is not well suited for this. That makes this idea an exciting potential for the future, but not a practical short-term goal. Well, but Peter's suggestion is the obvious next step - or even a necessary first step in my view. kgdb exists here and today in the kernel and you cannot just build a facility that doesnt replace it and doesnt integrate well with it. So if a unified user/kernel model for debugging is a 'long term' feature in your view then perhaps this framework (which introduces _extensive_ hooks all around the kernel) is not designed/approached in the right way and should not be merged in this form. Concentrating on 'other tools' just generates extensive dependencies on something that is lacking - making it even harder to implement unified debugging down the line. Thanks, Ingo
Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.
On Mon, Nov 30, 2009 at 04:16:50PM +0100, Ingo Molnar wrote: [...] kgdb exists here and today in the kernel and you cannot just build a facility that doesnt replace it and doesnt integrate well with it. Surely you don't mean that: every non-kgdb facility in the kernel meets that definition, even all debugging-related facilities such as perf and ftrace. So if a unified user/kernel model for debugging is a 'long term' feature in your view then perhaps this framework (which introduces _extensive_ hooks all around the kernel) is not designed/approached in the right way and should not be merged in this form. Which this framework are you talking about? Please clarify what exactly you're trying to say. - FChE
Re: clone bug (glibc?) (Was: clone-multi-ptrace test failure)
On 11/29, Roland McGrath wrote: Please file this test case on bugzilla.redhat.com for Fedora 12 glibc. https://bugzilla.redhat.com/show_bug.cgi?id=542731 Oleg.
Re: powerpc: syscall_dotrace() retcode (Was: powerpc: fork stepping)
On 11/30, Benjamin Herrenschmidt wrote: On Mon, 2009-11-30 at 10:15 +1100, Benjamin Herrenschmidt wrote: Yes, the asm should be changed. I suppose we could check if the result of do_syscall_trace_enter is negative, and if it is, branch to the exit path using r3 as the error code. Would that be ok ? Something like this: Note however that there's a trace exit too and that's normally the right place to alter the result don't you think ? Yes, the result can be changed when the tracee reports syscall-exit. Should powerpc allow this on syscall-entry? I do not know. x86 does, and we have this test-case which assumes powerpc should allow too. But when it comes to ptrace I can almost never know what was the supposed behaviour/api. Jan, Roland, what do you think? Oleg.
Re: powerpc: syscall_dotrace() retcode (Was: powerpc: fork stepping)
On 11/30, Benjamin Herrenschmidt wrote: On Sun, 2009-11-29 at 22:07 +0100, Oleg Nesterov wrote: If I change the test-case to use NEWVAL == 1000 (or any other value greater than NR_syscalls), then the tracee sees ENOSYS and this is correct too. But I do not see how it is possible to change the retcode on powerpc. Unlike x86, powepc doesn't set -ENOSYS in advance, before doing do_syscall_trace_enter() logic. This means that if the tracer cancels syscall, r3 will be overwritten by syscall_enosys. This probably means the kernel should be fixed too, but I am not brave enough to change the asm which I can't understand ;) Yes, the asm should be changed. I suppose we could check if the result of do_syscall_trace_enter is negative, and if it is, branch to the exit path using r3 as the error code. Would that be ok ? Something like this: --- a/arch/powerpc/kernel/entry_64.S +++ b/arch/powerpc/kernel/entry_64.S @@ -240,6 +240,9 @@ syscall_dotrace: bl .save_nvgprs addir3,r1,STACK_FRAME_OVERHEAD bl .do_syscall_trace_enter + cmpdi cr0,r3,0 + blt syscall_exit + Yes, but this doesn't allow to a) cancel this syscall and b) make it return a non-negative result to the tracee. Perhaps poweprc should set pt_regs-result = -ENOSYS before calling do_syscall_trace_enter() like x86 does ? (in this case syscall_exit() shouldn't change RESULT(r1)). This way the tracer can change both pt_regs-result and gpr[0] independently. Oleg.
Ofereça as melhores experiências de Portuga l com a garantia Lifecooler
Title: Untitled Document Coolgift é a nova marca de packs-oferta de experiências da Lifecooler. Doze gamas de vários temas de lazer, para todas as ocasiões e a preços muito acessíveis. Gamas COOLGIFT 4 Patas O melhor para os melhores amigos. Charme Urbano Palcos tertúlias e museus para espíritos urbanos. Espelho Meu Cuidados de imagem para quem está na moda. Zen´itude Experiências de corpo e alma para relaxar. Talentos Formação e diversão para amantes do saber. Sexy Descobertas sensuais para os 5 sentidos. Desafios Adrenalina para os mais ousados. FugasMúltiplos destinos para almas viajantes. RefúgiosLugares de sonho para despertar emoções. RA Estadias e práticas únicas para mais tarde recordar. JúniorGrandes diversões para os mais pequenos. WorkshopsMomentos práticos para quem quer aprender. Se não conseguir visualizar correctamente este email, clique aqui. Olá,Boas notícias para os fãs da Boa Vida. O Lifecooler acaba de lançar os seus novos packs-oferta de experiências. Uma selecção do melhor de Portugal para oferecer a toda a gente neste Natal! O presente e-mail destina-se única e exclusivamente a informar potenciais clientes e não pode ser considerado SPAM. De acordo com a legislação internacional que regulamenta o correio electrónico, "o e-mail não poderá ser considerado SPAM quando incluir uma forma do receptor ser removido da lista". Para não receber mais publicidade recomendada pelo lifecooler carregue aqui Copyright (C) 2007 Lifecooler
