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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 22 Oct 2009 08:59:47 -0700
From:	David Daney <ddaney@...iumnetworks.com>
To:	wuzhangjin@...il.com
CC:	rostedt@...dmis.org, linux-kernel@...r.kernel.org,
	linux-mips@...ux-mips.org, Thomas Gleixner <tglx@...utronix.de>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Nicholas Mc Guire <der.herr@...r.at>
Subject: Re: [PATCH -v4 9/9] tracing: add function graph tracer support for
 MIPS

Wu Zhangjin wrote:
> Hi,
> 
> On Wed, 2009-10-21 at 13:23 -0400, Steven Rostedt wrote:
>> On Wed, 2009-10-21 at 10:07 -0700, David Daney wrote:
>>
>>> I have not used -pg, so I don't know for sure, I think all it does is 
>>> add the calls to _mcount.  Someone could investigate 
>>> -fno-omit-frame-pointer, with that you may be able to use:
>> Note, -pg assumes -fno-omit-frame-pointer, since -fomit-frame-pointer
>> and -pg are incompatible.
> 
> Ralf have told me -pg really works with -fomit-frame-pointer, although
> the gcc tool tell us they are not incompatible when we use both of them
> together, but when I remove -fno-omit-frame-pointer in
> KBUILD_FLAGS(enabled by CONFIG_FRAME_POINTER), it definitely remove the
> s8(fp) relative source code(Seems -fomit-frame-pionter is used by
> default by gcc), the leaf function becomes this:
> 
> function:
> 
> 80101144 <au1k_wait>:
> 80101144:       03e00821        move    at,ra
> 80101148:       0c04271c        jal     80109c70 <_mcount>
> 
> No more instruction,
> 
> and the non-leaf function becomes,
> 
> 80126590 <copy_process>:
> 80126590:       27bdffa0        addiu   sp,sp,-96
> 80126594:       afbf005c        sw      ra,92(sp)
> 80126598:       afbe0058        sw      s8,88(sp)
> 8012659c:       afb70054        sw      s7,84(sp)
> 801265a0:       afb60050        sw      s6,80(sp)
> 801265a4:       afb5004c        sw      s5,76(sp)
> 801265a8:       afb40048        sw      s4,72(sp)
> 801265ac:       afb30044        sw      s3,68(sp)
> 801265b0:       afb20040        sw      s2,64(sp)
> 801265b4:       afb1003c        sw      s1,60(sp)
> 801265b8:       afb00038        sw      s0,56(sp)
> 801265bc:       03e00821        move    at,ra
> 801265c0:       0c04271c        jal     80109c70 <_mcount>
> 
> It may save about two instructions for us.
> 	
> 	sw	s8, offset(sp)
> 	move	s8, fp
> 
> and also, I have tried to just search "Save" instruction, if I find one,
> that should be a non-leaf function, otherwise, it's leaf function, but I
> can not prove no "Save" instruction before the leaf function's "move at,
> ra", for example:
> 
> 8010113c:       03e00008        jr      ra
> 80101140:       00020021        nop
> 
> 80101144 <au1k_wait>:
> 80101144:       03e00821        move    at,ra
> 80101148:       0c04271c        jal     80109c70 <_mcount>
> 
> if there is "save" instruction at address 80101140, it will fail.
> Although, I met not failure with several tries, but no prove on it! any
> ABI protection for this? if YES, this should be a better solution, for
> it may works without -fno-omit-frame-pointer and save several
> instructions for us.

This is what I was talking about up-thread.  Leaf functions may have no 
function prolog.  If you do code scanning you will fail.  While scanning 
backwards, there is no way to know when you have entered a new function. 
  Looking for function return sequences 'jr ra' doesn't work as there 
may be functions with multiple return sites, functions that never 
return, or arbitrary data before the function.  I think you have to 
force a frame pointer to be established if you want this to work.

David Daney
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ