Hi! On Mon, Nov 04, 2024 at 11:06:23PM +0530, Hari Bathini wrote: > Seems like a bit of misunderstanding there. Function entry here intends > to mean the actual start of function code (function prologue) - after > GEP and function profiling sequence (mflr r0; bl mcount). What you call "function entry" here simply does not exist. The compiler can -- and ***WILL***, ***DOES*** -- mix up all of that. In particular, "function prologue" does not exist at all (on any architecture worth its salt, including PowerPC), and all instructions you consider part of a function prologue might end up anywhere. The "profiling sequence" is part of that btw, and that typically ends up *not* the first thing in the function, not the first thing after the LEP (register saves are earlier often, they are generated in that order in the first place, but they can (and will) be moved if that schedules better). > Function arguments can be accessed with kprobe only while setting a > probe at an address the kernel treats as function start address. That is a silly assumption to make. There is no guarantee you can access function arguments *at all*, we're not in 1975 anymore. You *need* to look at debug information if you want to deal with anything about your high-level language program. Looking at the machine code can only tell you about the machine state, whatever is in registers etc. > Note that the test case pass criteria here is setting probe to fail by > providing an address (sym+offset) beyond the function start address. > > And in this specific test case (with "vfs_read+8", where vfs_read is > the symbol and '8' is the offset), the test case was failing on powerpc > because setting the probe at 'sym+8' was succeeding, as anywhere between > 'sym' to 'sym+16' is treated as function start address on powerpc: Yeah, fragile tests sometimes break. Changing a randomly chosen number to some other randomly chosen number will not fix the problem (but you can postpone having to deal with it, sure!) Segher
