Messages in this thread | | | Date | Tue, 04 Apr 2006 15:58:32 -0600 | From | "Christopher Friesen" <> | Subject | Re: CONFIG_FRAME_POINTER and module vermagic |
| |
A while back there was a post that CONFIG_FRAME_POINTER doesn't affect calling conventions and doesn't need to be in vermagic.
One of my coworkers seems to think otherwise, and I don't know enough about the issue to know for sure. Could someone with i386 knowledge comment on his thoughts?
Here's what he's currently thinking:
1) regs->ebp hold a copy of the stack frame pointer. It's value is conserved through any function that are compiled with FRAME_POINTER on.
2) (unsigned long *)(regs->ebp + 4) is the "pc" of the caller (like the link register on PPC which is relative to "fp")
3) The profile_pc function usually look directly at "pc" to do it's profiling magic but sometimes (when the current "pc" is inside a lock_function, we're SMP, and CONFIG_FRAME_POINTER is enabled) it uses "regs->ebp+4" to be more accurate on the profiling. In other word profile_pc doesn't want to create a profiling entry that would show redundant information about being stuck into a spin_lock...
So, if the kernel was built with SMP and FRAME_POINTER, a module wasn't, the module used ebp as a general register, then blocked in a spinlock when profile_pc started...then a regs->ebp value of something interesting (like "0", for instance) could cause interesting behaviour.
Seems reasonable to me, but like I said, I'm not an expert on i386.
Chris - 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/
| |