public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* What do IFUNC resolvers need to be useful?
@ 2016-03-04 16:42 Carlos O'Donell
  2016-03-04 18:07 ` Peter Bergner
  2016-03-04 18:23 ` Aurelien Jarno
  0 siblings, 2 replies; 5+ messages in thread
From: Carlos O'Donell @ 2016-03-04 16:42 UTC (permalink / raw)
  To: GNU C Library

Should IFUNC resolver get passed in a pointer to the
environment?

Aside from AT_HWCAPS, it would seem to me that the environment
would be the next most useful thing to control resolver behaviour
from the command line.

Anything else?

Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: What do IFUNC resolvers need to be useful?
  2016-03-04 16:42 What do IFUNC resolvers need to be useful? Carlos O'Donell
@ 2016-03-04 18:07 ` Peter Bergner
  2016-03-04 18:23 ` Aurelien Jarno
  1 sibling, 0 replies; 5+ messages in thread
From: Peter Bergner @ 2016-03-04 18:07 UTC (permalink / raw)
  To: Carlos O'Donell, GNU C Library

On Fri, 2016-03-04 at 11:42 -0500, Carlos O'Donell wrote:
> Should IFUNC resolver get passed in a pointer to the
> environment?
> 
> Aside from AT_HWCAPS, it would seem to me that the environment
> would be the next most useful thing to control resolver behaviour
> from the command line.
> 
> Anything else?

AT_PLATFORM ?

Peter

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: What do IFUNC resolvers need to be useful?
  2016-03-04 16:42 What do IFUNC resolvers need to be useful? Carlos O'Donell
  2016-03-04 18:07 ` Peter Bergner
@ 2016-03-04 18:23 ` Aurelien Jarno
  2016-03-22 15:05   ` Jose E. Marchesi
  1 sibling, 1 reply; 5+ messages in thread
From: Aurelien Jarno @ 2016-03-04 18:23 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: GNU C Library

On 2016-03-04 11:42, Carlos O'Donell wrote:
> Should IFUNC resolver get passed in a pointer to the
> environment?

I think that it would be a great improvement.

One can imagine to use that on the libc for example to temporarily
disable the optimized functions. That can be useful for debugging,
but also in our testsuite to test the various versions of a function.

One can also use an environment variable to enable logging, checking
or debugging without performance impact.

And I am sure people can have a lot more imagination about what to do
with such a possibility. Probably good things, but also bad things...

> Aside from AT_HWCAPS, it would seem to me that the environment
> would be the next most useful thing to control resolver behaviour
> from the command line.
> 
> Anything else?

Yes when using IFUNC to provide optimized version of some functions,
there is a need to determine the CPU capabilities. AT_HWCAP and
AT_HWCAP2 provide an easy way to do that. Alternatively we can pass
the whole auxiliary vector, that can give access to more values.
I guess one can imagine the use of at least AT_PAGESZ and AT_SECURE.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: What do IFUNC resolvers need to be useful?
  2016-03-04 18:23 ` Aurelien Jarno
@ 2016-03-22 15:05   ` Jose E. Marchesi
  2016-03-22 16:10     ` Szabolcs Nagy
  0 siblings, 1 reply; 5+ messages in thread
From: Jose E. Marchesi @ 2016-03-22 15:05 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: GNU C Library


    > Should IFUNC resolver get passed in a pointer to the
    > environment?
    
    I think that it would be a great improvement.
    
    One can imagine to use that on the libc for example to temporarily
    disable the optimized functions. That can be useful for debugging,
    but also in our testsuite to test the various versions of a
    function.

+1

Sometimes old code breaks with new optimized routines, such as
multithread issues in routines using block-initialize instructions in
sparc.  In these situations it would be very useful to disable certain
versions of the routines.

Also, it would allow users to easily benchmark the performance of the
routines applications/platforms and choose the best implementation for
them.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: What do IFUNC resolvers need to be useful?
  2016-03-22 15:05   ` Jose E. Marchesi
@ 2016-03-22 16:10     ` Szabolcs Nagy
  0 siblings, 0 replies; 5+ messages in thread
From: Szabolcs Nagy @ 2016-03-22 16:10 UTC (permalink / raw)
  To: Jose E. Marchesi, Carlos O'Donell; +Cc: GNU C Library, nd

On 22/03/16 15:13, Jose E. Marchesi wrote:
> 
>     > Should IFUNC resolver get passed in a pointer to the
>     > environment?
>     
>     I think that it would be a great improvement.
>     
>     One can imagine to use that on the libc for example to temporarily
>     disable the optimized functions. That can be useful for debugging,
>     but also in our testsuite to test the various versions of a
>     function.
> 
> +1
> 
> Sometimes old code breaks with new optimized routines, such as
> multithread issues in routines using block-initialize instructions in
> sparc.  In these situations it would be very useful to disable certain
> versions of the routines.
> 
> Also, it would allow users to easily benchmark the performance of the
> routines applications/platforms and choose the best implementation for
> them.
> 

so what should happen if a signal interrupts setenv
and the signal handler calls a function through plt
that needs ifunc resolution..

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-03-22 16:10 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-04 16:42 What do IFUNC resolvers need to be useful? Carlos O'Donell
2016-03-04 18:07 ` Peter Bergner
2016-03-04 18:23 ` Aurelien Jarno
2016-03-22 15:05   ` Jose E. Marchesi
2016-03-22 16:10     ` Szabolcs Nagy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).