Re: CVS commit: src/lib/libc/locale

[YAMAMOTO Takashi]

> On Thu, Apr 18, 2013 at 06:58:42AM +, YAMAMOTO Takashi wrote:
>> > On Tue, Apr 16, 2013 at 11:34:52PM +, YAMAMOTO Takashi wrote:
>> >> > On Tue, Apr 16, 2013 at 11:39:50PM +0900, Takehiko NOZAKI wrote:
>> >> >> so that the struct _locale __C_locale in libc is much more wasteful.
>> >> > 
>> >> > I should add that it is an internal detail and the way the composed C
>> >> > locale is stored can and likely will change later. So the way it is
>> >> > essentially a copy of (old) global locale is just a way to be minimally
>> >> > intrusive.
>> >> > 
>> >> > Joerg
>> >> 
>> >> i care the API.
>> >> 
>> >> if you really want it be in libc, how about having libc provide a
>> >> "locale_t get_static_c_locale();" style API rather than using NULL?
>> >> it's better because 1) less code in *_l, 2) autoconf-like can detect
>> >> the extension easily, and 3) a portable application can trivially
>> >> have a fallback implementation using newlocale+pthread_once.
>> > 
>> > It adds more cost on the caller side. So far, there are three mechanisms
>> > available (especially for libraries):
>> > 
>> > (1) Adhoc access to internal locale state. This is used with glibc.
>> > (2) Explicit newlocale().
>> > (3) Implicit access via 0 argument to *_l.
>> > 
>> > The first one is clearly a hack and not acceptable. Portable code can
>> > always conditionally use (2), but it requires additional setup and
>> > storage cost. (3) is used by Apple (which is where a large part of the
>> > *_l interface originates from) and FreeBSD. It is orthogonal to (2) and
>> > certainly easier to use. Exposing it via a special library call is also
>> > possible and effectively a way to implement (2) by a static wrapper.
>> > It still adds more cost to every caller and this is a classic case where
>> > there are typically much more callers.
>> > 
>> > Joerg
>> 
>> (3) adds small costs to every calls of *_l, even when the extension
>> is not used.  i sounds worse than a one-time cost of (2) to me.
> 
> (2) still needs to load the address (instead of a constant), so it isn't
> free either. Given that this is very popular as functionality and at
> least on modern CPUs often implementable as conditional-move, it sounds
> like a much better trade off.

very popular?  i'm not aware of a single software which uses this extension.
can you provide examples?

YAMAMOTO Takashi

> 
> Joerg

Re: CVS commit: src/sys/kern

[Matt Thomas]

On Apr 21, 2013, at 2:15 AM, David Laight  wrote:

> On Sat, Apr 20, 2013 at 02:17:17PM -0700, Matt Thomas wrote:
>> 
>> On Apr 20, 2013, at 11:04 AM, Christos Zoulas  wrote:
>> 
>>> Module Name:src
>>> Committed By:   christos
>>> Date:   Sat Apr 20 18:04:41 UTC 2013
>>> 
>>> Modified Files:
>>> src/sys/kern: kern_exec.c
>>> 
>>> Log Message:
>>> don't attempt to load elf64 on 32 bit machines
>> 
>> if the load address doesn't fit in 4GB.
>> 
>> I've run elf64(n64) on mips n32 kernel with no problems.
> 
> Isn't an n32 kernel a 64bit one that uses 32bit pointers?
> A little unusual.
> 
> Doesn't that require a COMPAT_64 layer in the kernel?
> Since user pointers will be 64bit and kernel ones only 32.

I cheated and used objcopy to convert a N32 binary to N64.

Re: CVS commit: src/sys/kern

[David Laight]

On Sat, Apr 20, 2013 at 02:17:17PM -0700, Matt Thomas wrote:
> 
> On Apr 20, 2013, at 11:04 AM, Christos Zoulas  wrote:
> 
> > Module Name:src
> > Committed By:   christos
> > Date:   Sat Apr 20 18:04:41 UTC 2013
> > 
> > Modified Files:
> > src/sys/kern: kern_exec.c
> > 
> > Log Message:
> > don't attempt to load elf64 on 32 bit machines
> 
> if the load address doesn't fit in 4GB.
> 
> I've run elf64(n64) on mips n32 kernel with no problems.

Isn't an n32 kernel a 64bit one that uses 32bit pointers?
A little unusual.

Doesn't that require a COMPAT_64 layer in the kernel?
Since user pointers will be 64bit and kernel ones only 32.

David

-- 
David Laight: da...@l8s.co.uk