[GHC] #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets:

[GHC]

#14261: ghc stopped recognizing some arm triplets that used to work: Failed to
lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available
targets:
-------------------------------------+-------------------------------------
        Reporter:  slyfox            |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by slyfox):

 > That being said, I am a bit confused about the armv7a-hardfloat-linux-
 gnueabi target. Shouldn't that be armv7-unknown-linux-gnueabihf

 This triplet is recognized by autoconf, gcc, glibc and binutils just fine
 and generated by GHC binaries worked.

 > Should we use Autoconf triple canonicalization here?

 I don't think canonicalization will give you much here. You can't match
 triples
 for exat match anyways. A few fields can be used to inject custom strings,
 like ${vendor}. I use ${vendor} a lot to distinct between locally
 installed
 toolchains (default-pie, default-nopie, etc.)

 {{{
 ghc $ ./config.sub armv7a-hardfloat-linux-gnueabi
 armv7a-hardfloat-linux-gnueabi
 ghc $ ./config.sub armv7a-unknown-linux-gnueabi
 armv7a-unknown-linux-gnueabi
 ghc  $ ./config.sub x86_64-UNREG-linux-gnu
 x86_64-UNREG-linux-gnu
 }}}

 I guess it depends what gen-data-layout.sh script tries to fish out of the
 triple.
 It looks like what it really needs is:
 - CPU architecture (that's the first field of triple)
 - FPU ABI

 Normally how autoconf scripts do it is they match for known templates:

 {{{
 case ${target} in
     armv[78]-*) something;;
     *-ghueabihf) something-else;;
     armv[678]-hardfloat-*) another-thing;;
     ...
 }}}

 It's a bit fragile though. More precise way would be to interrogate
 available toolchain.
 Either through dumping of defined macros for a target compiler and check
 for features you
 need to construct proper llvm string or compile-test things in autoconf
 way.

 If all above it tedious I'm fine to have a manual mechanism of passing
 required info manually at ./configure time (or whenever appropriate).

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