RE: Context of a kernel routine
> -Original Message- > From: kernelnewbies-bou...@nl.linux.org [mailto:kernelnewbies- > bou...@nl.linux.org] On Behalf Of Mulyadi Santosa > Sent: Sunday, September 19, 2010 8:13 AM > To: Vimal > Cc: Kernel Newbies > Subject: Re: Context of a kernel routine > > Hi.. > > On Sun, Sep 19, 2010 at 08:50, Vimal wrote: > > Most of the times, I just end up tracing the code path manually > from > > the source code. I have another question, though: Is it possible > in > > gdb to break on all function calls? Would be useful. :) > > > None that I know :) But maybe that is doable inside system emulator > such as Qemu. You need to trap the call of "call", "far jmp" or > things > like that. But the problem here is it is done system widely...thus > you > need a way to selectively filter which function calls you want to > trap > and which ones are not Regarding the code trace: Another approach which I used to use. It's ugly but worked for me most of the times. :-) We can use stack_trace()/dump_stack() functions (same routines which get called when kernel panics or Oops). Pass the stack pointer as NULL and it will dump the stack, register set of current process. Question is if it gets called multiple times and flood the console? You can create a sysctl entry - enable it (non-zero) from command prompt, once you get the expected trace - make sysctl_variable = 0 (will disable the function calls) :-) Something like: if(sysctl_variable) stack_trace(NULL); > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > -- Thanks, Nilesh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Context of a kernel routine
Mulyadi, Thanks. In fact, instead of setting breakpoints at all call or far jmps, I could set breakpoints for all functions. I think they are the same thing, unless there's some weird control flow. On 19 September 2010 08:55, Sri Ram Vemulpali wrote: > Replying to all. > Or you can set a timer which interrupts and checks the stack and prints > stack out. But you will get address of the instruction in the function. > you can see dtrace concept of hacking stack to insert callback functions to > trace callee. Sri, Thanks! Another approach would be to use "perf top", which I believe does something similar. -- Vimal -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Context of a kernel routine
Replying to all. Or you can set a timer which interrupts and checks the stack and prints stack out. But you will get address of the instruction in the function. you can see dtrace concept of hacking stack to insert callback functions to trace callee. Regards, Sri. On Sat, Sep 18, 2010 at 10:42 PM, Mulyadi Santosa wrote: > Hi.. > > On Sun, Sep 19, 2010 at 08:50, Vimal wrote: > > Most of the times, I just end up tracing the code path manually from > > the source code. I have another question, though: Is it possible in > > gdb to break on all function calls? Would be useful. :) > > > None that I know :) But maybe that is doable inside system emulator > such as Qemu. You need to trap the call of "call", "far jmp" or things > like that. But the problem here is it is done system widely...thus you > need a way to selectively filter which function calls you want to trap > and which ones are not > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > > -- > To unsubscribe from this list: send an email with > "unsubscribe kernelnewbies" to ecar...@nl.linux.org > Please read the FAQ at http://kernelnewbies.org/FAQ > > -- Regards, Sri.
Re: Context of a kernel routine
Hi.. On Sun, Sep 19, 2010 at 08:50, Vimal wrote: > Most of the times, I just end up tracing the code path manually from > the source code. I have another question, though: Is it possible in > gdb to break on all function calls? Would be useful. :) None that I know :) But maybe that is doable inside system emulator such as Qemu. You need to trap the call of "call", "far jmp" or things like that. But the problem here is it is done system widely...thus you need a way to selectively filter which function calls you want to trap and which ones are not -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Context of a kernel routine
Mulyadi and Sri Ram, Thanks for the inputs. I didn't know about the in_atomic() functions. But I am taking care not to cause bad things by checking if current is not null. > > The other way is to do code tracing by yourself. This method itself > can be done by the help of gdb or other debugger (break at the target > code and do backtracing) OR by doing manual code tracing. > Most of the times, I just end up tracing the code path manually from the source code. I have another question, though: Is it possible in gdb to break on all function calls? Would be useful. :) Thanks, -- Vimal -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Context of a kernel routine
Hi... On Sun, Sep 19, 2010 at 01:29, Vimal wrote: > Hi, > > How do I find out what functions in the kernel code are run in the > context of the process they're meant for? For e.g., when a TCP socket > receives a packet and it's being processed by some function, is the > code executing in the context of the process that created this socket? IMHO it's hard to say that method X is the finest way to identify it. I think the easiest way is to put the codes such as in_atomic(), in_interrupt() (I can't really recall the names) in the related codes and find out which codes that return true. The other way is to do code tracing by yourself. This method itself can be done by the help of gdb or other debugger (break at the target code and do backtracing) OR by doing manual code tracing. In both ways, you're tracking the execution path i.e where it is rooted. Most likely, long code path is running inside process context. In this case, it's piggybacking last process context (if executed by kernel threads) or running on behalf of current running process (in the case of syscalls). Maybe I miss something here, but hopefully you get the idea. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
