Hi,
On Mon, Mar 18, 2013 at 10:44 PM, Alan Modra amo...@gmail.com wrote:
On Mon, Mar 18, 2013 at 06:18:58PM +0100, Richard Biener wrote:
I was asking for the ifunc selector to be
Overridable by ld_preload or a similar mechanism at dynamic load time.
Please don't. Calling an ifunc resolver
On Mon, Mar 25, 2013 at 02:24:21PM -0700, Sriraman Tallam wrote:
Does this also mean that Paul's idea of doing:
LD_CPU_FEATURES=sse,sse2 ./a.out # run as if only sse and sse2 are available
is fraught with risk when used with IFUNC, particularly on x86_64?
Shouldn't the IFUNC resolver go
On Mon, Mar 18, 2013 at 06:18:58PM +0100, Richard Biener wrote:
I was asking for the ifunc selector to be
Overridable by ld_preload or a similar mechanism at dynamic load time.
Please don't. Calling an ifunc resolver function in another library
is just asking for trouble with current glibc.
H.J. Lu hjl.to...@gmail.com wrote:
On Mon, Mar 18, 2013 at 10:02 AM, Paul Pluzhnikov
ppluzhni...@google.com wrote:
+cc libc-alpha
On Mon, Mar 18, 2013 at 9:05 AM, Xinliang David Li
davi...@google.com wrote:
Interesting idea about lazy IFUNC relocation.
On Mon, Mar 18, 2013 at 2:02 AM,
On Mon, Mar 18, 2013 at 10:02 AM, Paul Pluzhnikov
ppluzhni...@google.com wrote:
+cc libc-alpha
On Mon, Mar 18, 2013 at 9:05 AM, Xinliang David Li davi...@google.com wrote:
Interesting idea about lazy IFUNC relocation.
On Mon, Mar 18, 2013 at 2:02 AM, Richard Biener
+cc libc-alpha
On Mon, Mar 18, 2013 at 9:05 AM, Xinliang David Li davi...@google.com wrote:
Interesting idea about lazy IFUNC relocation.
On Mon, Mar 18, 2013 at 2:02 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Mar 15, 2013 at 10:55 PM, Sriraman Tallam tmsri...@google.com
On Mon, Mar 18, 2013 at 10:18 AM, Richard Biener
richard.guent...@gmail.com wrote:
H.J. Lu hjl.to...@gmail.com wrote:
We can pass environment variables to IFUNC selector. Maybe we can
enable it for debug build.
Enabling this for just debug builds would not cover my use case.
If the
Interesting idea about lazy IFUNC relocation.
David
On Mon, Mar 18, 2013 at 2:02 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Mar 15, 2013 at 10:55 PM, Sriraman Tallam tmsri...@google.com wrote:
Hi,
This patch is meant for google/gcc-4_7 but I want this to be
considered
Hi,
This patch is meant for google/gcc-4_7 but I want this to be
considered for trunk when it opens again. This patch makes it easy to
test for code coverage of multiversioned functions. Here is a
motivating example:
__attribute__((target (default))) int foo () { ... return 0; }
On Fri, Mar 15, 2013 at 2:55 PM, Sriraman Tallam tmsri...@google.com wrote:
Hi,
This patch is meant for google/gcc-4_7 but I want this to be
considered for trunk when it opens again. This patch makes it easy to
test for code coverage of multiversioned functions. Here is a
motivating
On Fri, Mar 15, 2013 at 3:37 PM, Xinliang David Li davi...@google.com wrote:
On Fri, Mar 15, 2013 at 2:55 PM, Sriraman Tallam tmsri...@google.com wrote:
Hi,
This patch is meant for google/gcc-4_7 but I want this to be
considered for trunk when it opens again. This patch makes it easy to
Ok. If the use case is to enable the test of the same application
binary (not the per function unit test) with CPU mocking at runtime
(via environment variable or application specific flags), the proposed
changes make sense.
David
On Fri, Mar 15, 2013 at 3:49 PM, Sriraman Tallam
12 matches
Mail list logo
