linux-kernel - Re: Ftrace for Microblaze

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1d3f23370911031826u1a601db1jab678030eafd200e@mail.gmail.com>
Date:	Wed, 4 Nov 2009 12:26:42 +1000
From:	John Williams <john.williams@...alogix.com>
To:	rostedt@...dmis.org
Cc:	monstr@...str.eu, Steven Rostedt <srostedt@...hat.com>,
	mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: Re: Ftrace for Microblaze - notrace

>>  From my test I don't understand MCOUNT_INSN_SIZE - and which function
>> doesn't care about. There is this line of pseudocode in your doc
>> (unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE;) but what
>> the reason is to do that. If I understand correct selfpc and frompc just
>> give addresses which functions called that mcount and has impact to log.
>> I mean that if that address is not proper begin of function is found
>> (not sure if the code do it or not) function name (and function) which
>> contain that address. Or is there any special reason why to substract
>> that MCOUNT_INSN_SIZE - for timing or anything like that?
>
> The passed in address to mcount is really the return address and not the
> caller to mcount. We want the actual address to the mcount caller. To
> get that we must subtract size of the call to mcount from the address
> passed in.

Is it critical that mcount calculate and use the exact entry point of
the calling function, or just that it be consistent and be located
"inside" the caller's footprint?  If so, MCOUNT_INSN_SIZE would be
superfluous?...

MicroBlaze gcc currently inserts the mcount call after the function
prologue, and the prologue will differ in length depending upon how
much stack and register shuffling is required for that function.  So,
a single constant cannot correctly describe the offset of the mcount
call site to the function's true entry point.

Or, perhaps the entry point is defined as "the first opcode after the
prologue", in which case MCOUNT_INSN_SIZE can just be the size of the
"bralid r15, _mcount; nop" sequence that we are generating (ie 8
bytes).

There is a simple GCC #define that will force the mcount branch before
the prologue, but that makes things a little trickier because our
mcount hook must take care of saving away the branch link register.
If we call after the prologue, gcc has already done that for us.

Thanks,

John
-- 
John Williams
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/