Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,968
    • Issues 4,968
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 474
    • Merge requests 474
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #11744
Closed
Open
Created Mar 23, 2016 by Herbert Valerio Riedel@hvr🕺Maintainer

Latest Xcode update violates POSIX compliance of `nm -P`

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.

  1. ..

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>

  1. ..

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

Edited Mar 10, 2019 by Herbert Valerio Riedel
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking