[GHC] #10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales

[GHC]

#10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..)
locales
-------------------------------------+-------------------------------------
        Reporter:  hgolden           |                   Owner:  simonmar
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:  7.12.1
       Component:  Runtime System    |                 Version:  7.8.4
  (Linker)                           |                Keywords:  linker
      Resolution:                    |  script
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  Incorrect result  |  Unknown/Multiple
  at runtime                         |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:  2615, 9237        |  Differential Revisions:
-------------------------------------+-------------------------------------
Description changed by ezyang:

Old description:

> Please see ticket:2615#comment:40 and replies.
>
> This error only occurs on systems where linker scripts are used. The
> linker script patch (as it has evolved) assumes that the error messages
> it will receive are in English. This would be true if the locale
> (LC_MESSAGES) is C or en (or one of the en variants). However, in other
> locales, the message will be in a different language. Unfortunately, the
> semantics of POSIX dlerror() specify that the error is returned as a
> pointer to a human-readable text string, rather than an error code. The
> string returned depends on the locale.
>
> The code could be made more robust by momentarily changing the locale
> (LC_MESSAGES) to C before calling dlerror() and reverting it to its
> previous value immediately after. This has been tested on a zh_CN.utf-8
> (see ticket:2615#comment:42) and works. The only concern I have is in the
> case of multithreaded code that _might_ be affected if it is running
> while the locale is changed. I don't know enough to know if this is a
> real issue or not, nor do I know how to deal with it if necessary.
>
> Also see ticket:9237 for another corner case in the linker script code
> that should be dealt with at the same time.

New description:

 Please see ticket:2615#comment:40 and replies.

 A bug is illustrated by this Haskell program:

 {{{
 import ObjLink
 import Foreign
 import Foreign.C.Types
 import Foreign.C.String

 foreign import ccall "setlocale" c_setlocale :: CInt -> CString -> IO
 CString

 main = do
   withCString "zh_CN.UTF-8" $ \lc -> c_setlocale 5 lc
   r <- loadDLL "/usr/lib/libc.so"
   putStrLn (show r)
 }}}

 which outputs:

 {{{
 Just "/usr/lib/libc.so: \26080\25928\30340 ELF \22836"
 }}}

 The "\26080\25928\30340 ELF \22836" part is "无效的ELF头" in Chinese.

 This error only occurs on systems where linker scripts are used. The
 linker script patch (as it has evolved) assumes that the error messages it
 will receive are in English. This would be true if the locale
 (LC_MESSAGES) is C or en (or one of the en variants). However, in other
 locales, the message will be in a different language. Unfortunately, the
 semantics of POSIX dlerror() specify that the error is returned as a
 pointer to a human-readable text string, rather than an error code. The
 string returned depends on the locale.

 The code could be made more robust by momentarily changing the locale
 (LC_MESSAGES) to C before calling dlerror() and reverting it to its
 previous value immediately after. This has been tested on a zh_CN.utf-8
 (see ticket:2615#comment:42) and works. The only concern I have is in the
 case of multithreaded code that _might_ be affected if it is running while
 the locale is changed. I don't know enough to know if this is a real issue
 or not, nor do I know how to deal with it if necessary.

 Also see ticket:9237 for another corner case in the linker script code
 that should be dealt with at the same time.

--

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10046#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler