linux-kernel - Re: BUG: GCC-4.4.x changes the function frame on some functions

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: <1258663464.22249.999.camel@gandalf.stny.rr.com>
Date:	Thu, 19 Nov 2009 15:44:24 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	David Daney <ddaney@...iumnetworks.com>,
	Andrew Haley <aph@...hat.com>,
	Richard Guenther <richard.guenther@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	feng.tang@...el.com, Peter Zijlstra <peterz@...radead.org>,
	jakub@...hat.com, gcc@....gnu.org
Subject: Re: BUG: GCC-4.4.x changes the function frame on some functions

On Thu, 2009-11-19 at 12:36 -0800, Linus Torvalds wrote:
> 
> On Thu, 19 Nov 2009, Frederic Weisbecker wrote:
> >
> > > That way the lr would have the current function, and the parent would
> > > still be at 8(%sp)
> > 
> > Yeah right, we need at least such very tiny prologue for
> > archs that store return addresses in a reg.
> 
> Well, it will be architecture-dependent.

Totally agree, as mcount today is architecture dependent.

> 
> For example, alpha can store the return value in _any_ register if I 
> recall correctly, so you can do the "call to __fentry__" by just picking 
> another register than the default one as the return address.
> 
> And powerpc has two special registers: link and ctr, but iirc you can only 
> load 'link' with a branch instruction. Which means that you could do 
> something like 
> 
> 	mflr 0
> 	bl __fentry__
> 
> in the caller (I forget if R0 is actually a call-trashed register or not), 
> and then __fentry__ could do something like
> 
> 	mflr 12		# save _new_ link
> 	mtlr 0		# restore original link
> 	mtctr 12	# move __fentry__ link to ctr
> 	.. do whatever ..
> 	bctr		# return to __fentry__ caller
> 
> to return with 'link' restored (but ctr and r0/r12 trashed - I don't 
> recall the ppc calling conventions any more, but I think that is ok).
> 
> Saving to stack seems unnecessary and pointless.

I was just using an example. But as you pointed out, each arch can find
its best way to handle it. Having the profiler called at the beginning
of the function is what I feel is the best.

We also get access to the function's parameters :-)


-- Steve


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