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 chris...@netbsd.org 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

Re: CVS commit: src/sys/kern

[Matt Thomas]

On Apr 21, 2013, at 2:15 AM, David Laight da...@l8s.co.uk wrote:

 On Sat, Apr 20, 2013 at 02:17:17PM -0700, Matt Thomas wrote:
 
 On Apr 20, 2013, at 11:04 AM, Christos Zoulas chris...@netbsd.org 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/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