On Fri, 29 May 2009, Wu Zhangjin wrote: > > > + > > > +NESTED(ftrace_graph_caller, PT_SIZE, ra) > > > + MCOUNT_SAVE_REGS > > > + > > > + MCOUNT_SET_ARGS > > > + jal prepare_ftrace_return > > > + nop > > > + > > > + /* overwrite the parent as &return_to_handler: v0 -> $1(at) */ > > > + PTR_S v0, PT_R1(sp) > > > + > > > + MCOUNT_RESTORE_REGS > > > + RETURN_BACK > > > + END(ftrace_graph_caller) > > > + > > > + .align 2 > > > + .globl return_to_handler > > > +return_to_handler: > > > + MCOUNT_SAVE_REGS > > > > I'm not sure which version of function_graph tracer you looked at, > > currently, I'm using the master branch of the latest linux-mips git > tree. so, the function_graph should be the latest version? > > BTW: which git branch should i apply these patches to? Any changes to the core ftrace we would like to go through tip. But testing of an arch is best in the arch specific trees. What we did for powerpc, was that we made a branch based off of linus's tree and did only the change in the core ftrace code that was needed by PPC. Then that branch was pulled into both tip and the ppc git tree. Thus it was the same change set with the same SHA1. Then it could go via either ppc or tip into linus's tree and it would not be a duplicate. We might need to do something similar as well for mips. > > > but I'm > > pretty sure you can just save the return code registers of the function. > > > > return_to_handler is called on the return of a function. > > Yeap. > > > Thus, any callee > > saved registers have already been restored and would also be restored by > > ftrace_return_to_handler. Any callee registers would have been saved by > > the function you are about to return to. > > > > Thus the only things you need to save are the return code registers. > > have tried to not save/restore the arguments(a0-7) registers, the kernel > will hang: You might want to look into this. When Frederic first did the code for x86_64 he had similar issues. But later I converted it to just the return values and everything worked fine. You might be hiding some other kind of bug. But I don not remember the mips binary api. Does the callee own all args registers? or just the ones it uses. You must also make sure you preserve all return value registers. Again, I don't remember mips api (been 8 years since I've worked on mips), but it may be more than one reg. /me searches for his old mips hand book. > > CPU 0 Unable to handle kernel paging request at virtual address > 0000000c, epc == 80101360, ra == 8010b114 > Oops[#1]: > Cpu 0 > $ 0 : 00000000 8010b114 00000000 00000000 > $ 4 : 87830d00 87830d00 8780c380 10002400 > $ 8 : 5607ec00 0000000b 00000000 5607ec00 > $12 : 5607ec00 9e3779b9 9e3779b9 00000000 > $16 : 00000000 10002400 00000000 87884d00 > $20 : 000000d0 801857cc 00000000 80483e00 > $24 : 00000000 00000000 > $28 : 87976000 87977cd8 87977cd8 8010b114 > Hi : 0000000b > Lo : 5607ec00 > epc : 80101360 plat_irq_dispatch+0x70/0x250 > Not tainted > ra : 8010b114 return_to_handler+0x0/0x4c > Status: 10002402 KERNEL EXL > Cause : 50808008 > BadVA : 0000000c > PrId : 00019300 (MIPS 24Kc) > Process bash (pid: 533, threadinfo=87976000, task=8796f560, > tls=2aad5100) > Stack : 00000062 0000006f 80455ef8 9e3779b9 00000000 00000020 87977da8 > 80101f80 > 804b0000 804b0000 87977d08 8010b330 00000000 80483e00 00000000 > 10002401 > 00000000 00000000 804b0000 804b3854 00000000 00000004 08042c2b > 8010b0a0 > 00000000 0000005f 80455fe4 9e3779b9 9e3779b9 00000000 87884d80 > 00000020 > 00000000 87884d00 000000d0 801857cc 00000000 80483e00 00000000 > 00000000 > ... > Call Trace: > [<80101360>] plat_irq_dispatch+0x70/0x250 > [<80101f80>] ret_from_irq+0x0/0x4 > [<80183dd4>] ftrace_run_update_code+0x58/0xdc > [<8018410c>] ftrace_startup+0x7c/0x90 > [<80185ab8>] register_ftrace_graph+0x40c/0x440 > [<801955a0>] graph_trace_init+0x28/0x54 > [<80190d00>] tracer_init+0x34/0x50 > [<80190f34>] tracing_set_tracer+0x218/0x2c4 > [<801910b8>] tracing_set_trace_write+0xd8/0x144 > > > Code: 00000000 0c05cc3c 02002021 <8c43000c> 02002021 0060f809 > 00402821 0c04cec0 00000000 > Disabling lock debugging due to kernel taint > Kernel panic - not syncing: Fatal exception in interrupt > > so, i think there is really a need to use the current > MCOUNT_SAVE/RESTORE_REGS, some arguments registers should be saved. > and we can share this common macros :-) I would still like to understand why it crashes. Perhaps you really need to save all regs, but not fully understanding a crash and finding a work around does not make me feel too comfortable. -- Steve
