[GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P`
GHC
ghc-devs at haskell.org
Wed Mar 23 23:06:37 UTC 2016
#11744: Latest Xcode update violates POSIX compliance of `nm -P`
---------------------------------+----------------------------------------
Reporter: hvr | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Build System | Version:
Resolution: | Keywords:
Operating System: MacOS X | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
---------------------------------+----------------------------------------
Description changed by hvr:
@@ -80,0 +80,13 @@
+
+ ----
+
+ Alternative workaround (since it turns out that Apple's `nm` violates
+ POSIX even more than assumed by not even supporting `nm -P -t x`):
+
+ Have `deriveConstants` derive a known value, e.g. the value `0x1234` via
+ `char derivedConstantCONTROL_GROUP[1+0x1234];`, and if the value for
+ `CONTROL_GROUP` comes back as `18016` we know that we need to fixup all
+ decimal-wrongly-as-hex parsed integers, if it comes back as `4660` we
+ parsed correctly; any different value is a non-recoverable error
+
+ This would also serve as a general integrity check for //all// platforms
New description:
TLDR: Apple messed up again and broke POSIX compliance
luite ran into problems when he installed the latest Xcode update because
the derived platform constants were off.
He provided me the output of `nm -P ./includes/dist-
derivedconstants/header/tmp.o` which turned out to have numbers which
didn't make sense:
{{{
_derivedConstantAP_STACK_SPLIM C 1025 0
_derivedConstantBITMAP_BITS_SHIFT C 7 0
_derivedConstantBLOCKS_PER_MBLOCK C 253 0
_derivedConstantBLOCK_SIZE C 4097 0
_derivedConstantCINT_SIZE C 5 0
_derivedConstantCLONG_LONG_SIZE C 9 0
_derivedConstantCLONG_SIZE C 9 0
_derivedConstantDOUBLE_SIZE C 9 0
_derivedConstantDYNAMIC_BY_DEFAULT C 2 0
...
}}}
Which with an older Xcode version would have looked like
{{{
_derivedConstantAP_STACK_SPLIM C 401 0
_derivedConstantBITMAP_BITS_SHIFT C 7 0
_derivedConstantBLOCKS_PER_MBLOCK C fd 0
_derivedConstantBLOCK_SIZE C 1001 0
_derivedConstantCINT_SIZE C 5 0
_derivedConstantCLONG_LONG_SIZE C 9 0
_derivedConstantCLONG_SIZE C 9 0
_derivedConstantDOUBLE_SIZE C 9 0
_derivedConstantDYNAMIC_BY_DEFAULT C 2 0
...
}}}
So obviously `nm -P`'s output changed from hexadecimal to (non-compliant)
decimal formatting of numbers.
For reference, here's how POSIX specifies the semantics of `nm`:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/nm.html
----
> `-P`
> Write information in a portable output format, as specified in the
STDOUT section.
...
> If the `-P` option is specified, the previous information shall be
displayed using the following portable format. The three versions differ
depending on whether `-t d`, `-t o`, or `-t x` was specified,
respectively:
>
> {{{"%s%s %s %d %d\n", <library/object name>, <name>, <type>, <value>,
<size>}}}
>
> {{{"%s%s %s %o %o\n", <library/object name>, <name>, <type>, <value>,
<size>}}}
>
> {{{"%s%s %s %x %x\n", <library/object name>, <name>, <type>, <value>,
<size>}}}
...
> '''If `-P` is specified, but `-t` is not, the format shall be as if `-t
x` had been specified.'''
----
In the event that Apple can't be bothered to fix this bug (I've had bad
experience with Apple and standard-compliance in the past, hence my
pessimism) we could try to workaround by using `nm -P -t x` when building
on OSX...
----
Alternative workaround (since it turns out that Apple's `nm` violates
POSIX even more than assumed by not even supporting `nm -P -t x`):
Have `deriveConstants` derive a known value, e.g. the value `0x1234` via
`char derivedConstantCONTROL_GROUP[1+0x1234];`, and if the value for
`CONTROL_GROUP` comes back as `18016` we know that we need to fixup all
decimal-wrongly-as-hex parsed integers, if it comes back as `4660` we
parsed correctly; any different value is a non-recoverable error
This would also serve as a general integrity check for //all// platforms
--
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11744#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list