summaryrefslogtreecommitdiff
path: root/config/arch/arm.in
blob: 269310d68a5472a0d726c57d28919f152f8880e5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
# ARM specific configuration file

## select ARCH_SUPPORTS_32
## select ARCH_SUPPORTS_64
## select ARCH_DEFAULT_32
## select ARCH_SUPPORTS_BOTH_MMU
## select ARCH_DEFAULT_HAS_MMU
## select ARCH_SUPPORTS_BOTH_ENDIAN
## select ARCH_DEFAULT_LE
## select ARCH_SUPPORTS_WITH_ARCH
## select ARCH_SUPPORTS_WITH_CPU
## select ARCH_EXCLUSIVE_WITH_CPU
## select ARCH_SUPPORTS_WITH_TUNE
## select ARCH_SUPPORTS_WITH_FLOAT if ARCH_32
## select ARCH_SUPPORTS_WITH_FPU if ARCH_32
## select ARCH_SUPPORTS_SOFTFP if ARCH_32

## help The ARM architecture, as defined by:
## help     http://www.arm.com/

if ARCH_32
config ARCH_ARM_MODE
    string
    default "arm"   if ARCH_ARM_MODE_ARM
    default "thumb" if ARCH_ARM_MODE_THUMB

choice
    bool
    prompt "Default instruction set mode"
    default ARCH_ARM_MODE_ARM

config ARCH_ARM_MODE_ARM
    bool
    prompt "arm"
    help
      Defaults to emitting instructions in the ARM mode.

config ARCH_ARM_MODE_THUMB
    bool
    prompt "thumb"
    help
      Defaults to emitting instructions in the THUMB mode.

endchoice

config ARCH_ARM_INTERWORKING
    bool
    prompt "Use Thumb-interworking (READ HELP)"
    help
      Excerpt from the gcc manual:
      
      > Generate code which supports calling between the ARM and Thumb
      > instruction sets. Without this option the two instruction sets
      > cannot be reliably used inside one program. The default is
      > [not to use interwork], since slightly larger code is generated
      > when [interwork] is specified.
      
      NOTE: Interworking in crosstool-NG is not sell-tested. Use at your
            own risks, and report success and/or failure.

# Until we only support EABI:
config ARCH_ARM_ABI_OK
    def_bool y
    depends on ! ARCH_ARM_EABI
    select ARCH_SUPPORTS_WITH_ABI

# Little trick to force EABI *and* always show the prompt
config ARCH_ARM_EABI_FORCE
    bool
    default y if ! OBSOLETE
    select ARCH_ARM_EABI

config ARCH_ARM_EABI
    bool
    prompt "Use EABI"
    default y
    help
      Set up the toolchain so that it generates EABI-compliant binaries.
      
      If you say 'n' here, then the toolchain will generate OABI binaries.
      OABI has long been deprecated, and is now considered legacy.

config ARCH_ARM_TUPLE_USE_EABIHF
    bool
    prompt "append 'hf' to the tuple (EXPERIMENTAL)"
    depends on ARCH_FLOAT_HW
    depends on ARCH_ARM_EABI    # Until we only support that...
    default y
    help
      Is you say 'y' here, then the tuple for the toolchain will end
      up with *eabihf, instead of the usual *eabi.

      *eabihf is used to denote that the toolchain *is* using the
      hard-float ABI, while *eabi is just an indication of using the
      soft-float ABI.

      Ie. all one can say is:  *eabihf ⊢ hard-float ABI

      Saying 'n' here does *not* impact the ability of the toolchain to
      generate hard-float instructions with the hard-float ABI. It is a
      purely cosmetic thing, used by distros to differentiate their
      hard-float-ABI-using ports from their soft-float-ABI-using ports.
      (eg. Debian Wheezy and above).

      This is an option, as not all versions of gcc/binutils do support
      such tuple, and fail to build with *eabihf. Stock gcc version up
      to, and including 4.7.2 have an issue or another with *eabihf.

      This option is here for the future.

      Say 'n', unless you are trying to fix gcc to properly recognise
      the *eabihf tuples.

endif