4.1.3. Converting TI-Syntax Assembly Directives to GNU-Syntax Assembly Directives

While the code actually executed by applications is made up of assembly language instructions, an assembly language source file makes extensive use of directives to create code sections and data sections that can be manipulated at link time to bind code and data to specific target memory locations. Directives are also used to define symbols, define data-objects, and communicate debug information via the object file created by the assembler.

As described previously, instructions written in legacy TI-syntax are likely to be relatively portable to GNU-syntax. However, there are extensive differences in the directives used by legacy TI-syntax and GNU-syntax. The majority of the effort required to migrate a legacy TI-syntax assembly language source file to GNU-syntax will likely involve modifying directives.

This section addresses the problem of transforming legacy TI-syntax assembly directives to be GNU-syntax compatible. First, general differences in the fields of a directive are discussed. These differences apply to one or more directives.

Second, each category of directives available in legacy TI-syntax Arm assembly language will be presented with guidance about how to convert a given legacy TI-syntax directive into its functionally equivalent GNU-syntax counterpart, if one exists.

Finally, the last two sections will present legacy TI-syntax directives that do not have a functionally equivalent GNU-syntax counterpart.

4.1.3.1. Anatomy of a Directive

4.1.3.1.1. Labels

For both legacy TI-syntax and GNU-syntax Arm assembly language, the label field begins in the leftmost column and contains a legal identifier that becomes the name of a symbol that will be assigned a value. In the context of a directive, the meaning of the label symbol and the value assigned to it depend upon the semantics of the directive that the label is associated with.

In legacy TI-syntax, symbols specified in the label field are not required to be terminated with a colon (‘:’). Several directives in the legacy TI-syntax require that a symbol be specified in the label field on the same line as the directive. For example, the “.set” directive assigns a value to a symbol where the symbol to be defined is specified in the label field and the value that is assigned to the symbol is specified as the single operand in the operand field:

define_me   .set   10

In this case, the “define_me” symbol specified in the label field cannot be placed on a separate line from the .set directive in legacy TI-syntax.

GNU-syntax supports a directive identified with the “.equ” mnemonic identifier, but with different syntax rules for the operand field. The above “.set” legacy TI-syntax directive is equivalent to the following GNU-syntax directive:

.equ   define_me, 10

Instead of a single operand indicating the value to be assigned to “define_me”, the GNU-syntax “.equ” directive requires two operands in the operand field. The first specifies the symbol name being defined, and the second provides the value to be associated with the symbol.

In GNU-syntax, a mnemonic field that begins in the leftmost column is distinguished from a label field that must begin in the leftmost column of an assembly source line by the requirement that a label field identifier be terminated with a colon (‘:’). Consequently, in GNU-syntax, the sole purpose of a label is to associate an address value with the symbol name specified in the label field. While GNU-syntax directives do not require a label, some legacy TI-syntax directives do. If a legacy TI-syntax directive is described as having a symbol preceding the mnemonic field, then it can be assumed that the symbol is to be defined in the label field and is required according to legacy TI-syntax rules.

4.1.3.1.2. Mnemonics

In both the legacy TI-syntax and GNU-syntax assembly languages, directives can be easily distinguished from instructions because the mnemonic identifier associated with a directive begins with period (‘.’) and instructions do not.

The major difference between a directive mnemonic in legacy TI-syntax and a directive mnemonic in GNU-syntax is that a mnemonic in legacy TI-syntax may not begin in the leftmost column of a line of assembly. GNU-syntax allows a mnemonic field to begin in the leftmost column of an assembly source line as long as the identifier specified in the mnemonic field is not terminated with a colon (‘:’). If the identifier starts in the leftmost column and is terminated with a colon (‘:’), then tiarmclang interprets that identifier as a label specification.

4.1.3.2. Operands

Symbols

In assembly language a symbol represents some value. If the value is known at assembly time, the symbol becomes an alias for that value. This is useful if the value of a symbol is dependent on a configuration. For example, you might use conditional directives to define a symbol whose value is dependent on which variant of the Arm architecture you are assembling for:

.if      __ARM_ARCH == 7
.equ     my_coeff, 10
.else
.equ     my_coeff, 1
.endif

Note that GNU-syntax Arm assembly language supports the same list of ACLE pre-defined symbols that are supported in C/C++ by the tiarmclang compiler.

Perhaps the most common way that symbols are defined and referenced in assembly source is as representatives for a particular address in memory. In such cases, a symbol is usually defined by a label. The label is associated with a particular location in memory that may not be known until link-time, and so references to the label symbol are typically accompanied by a relocation entry that helps the linker resolve the final value of the symbol at link time and patch each reference to the symbol according to the context in which the label symbol was referenced.

Immediates

Unlike instruction syntax, immediate operands for directives are not prefixed with a hash (‘#’). In both legacy TI-syntax and GNU-syntax, the legality of where an immediate value is specified, as an operand or as part of an expression, depends on the directive specification in which the immediate occurs. Some directives, like GNU-syntax’s “.balign”, require an operand that evaluates at assembly time to be an integer constant. In the following GNU-syntax “.org” directive, an immediate is specified in the context of an expression to allocate space that can be accessed through the label symbol “start_addr”:

start_addr:
       .org   start_addr + 0x100

Built-In Functions and Operators

The legacy TI-syntax supports a rich set of built-in functions and operators detailed in the Arm Assembly Language Tools User’s Guide. These are trigonometric and other arithmetic and symbolic functions that can be evaluated by the legacy TI-syntax assembler at assembly time and resolve to a legal value for the context in which they occur.

GNU-syntax does not support the built-in functions and operators that are available to the legacy TI-syntax assembler.

4.1.3.3. TI-Syntax Assembly Directives and Their GNU-Syntax Counterparts

In the subsections below, a group of commonly occurring legacy TI-syntax directives is listed along with guidance about how each legacy TI-syntax directive can be converted into a functionally equivalent GNU-syntax directive that is compatible with the tiarmclang’s integrated assembler.

4.1.3.3.1. Section Directives

Anything that requires space - be it code, read-only data, or read-write data - will be contained in the assembly language’s notion of a section. While the migration of legacy TI-syntax initialized sections to a GNU-syntax representation is reasonably straightforward, the migration of uninitialized sections in legacy TI-syntax to a functional equivalent in GNU-syntax is more involved.

In legacy TI-syntax assembly source, a user can allocate space and define a label symbol whose value is the starting address of that allocated space all with a single directive. The following assembly source contains a legacy TI-syntax .usect directive:

       .text
       nop
XYZ    .usect ".bss:XYZ", 8, 4
       nop

This example allocates a space of 8 bytes on a 4-byte boundary within a section called “.bss:XYZ”. It also defines a symbol called “XYZ” whose value is the address of the first byte in the “.bss:XYZ” section that is allocated by this directive. Since the space allocated by the .usect directive contains no data, it is called an “uninitialized” section in the legacy TI-syntax. The GNU-syntax functional equivalent of the above .usect directive is a sequence of multiple assembly source lines:

       .text
       nop
       .section .bss.XYZ, "aw", %nobits
       .p2align 2
XYZ:
       .zero 8
       .text
       nop

There are several interesting characteristics of this migration example to take note of:

• GNU-syntax does not make a distinction between initialized and uninitialized sections via the directive mnemonic name like legacy TI-syntax does (e.g. .sect vs. .usect). Instead, the section type flag operand, “%nobits”, indicates to the assembler that what follows the .section directive only represents space that is contained in the “.bss.XYZ” section and implies that the load image of the “.bss.XYZ” section is not initialized with any data.

• The “aw” section flags indicate that the “.bss.XYZ” section is allocatable and writable

• While the legacy TI-syntax’s .usect directive uses both a size and alignment operand to indicate the details of the space allocated, this functionality is carried out with the lines after the .section directive in GNU-syntax:

  • The GNU-syntax .p2align directive explicitly aligns the “.bss.XYZ” section’s program counter to the next 4-byte boundary.

  • The “XYZ:” label defines a symbol whose value is the newly aligned “.bss.XYZ” section program counter.

  • The .zero 8 directive then marks off 8 bytes of space in the section, the first byte of which is pointed to by XYZ.

• Another characteristic of the legacy TI-syntax’s .usect directive is that it acts as a temporary escape from the current section (.text in the example), allocates space into the “.bss:XYZ” section, and then implicitly returns the assembler to the section that it was in when the .usect was encountered. (In this example, the assembler implicitly returns to the .text section after processing the .usect directive.) In contrast, the GNU-syntax’s .section directive instructs the assembler to start assembling into the “.bss.XYZ” section, but it requires an explicit .text directive to instruct the assembler to return to assembling instructions into the .text section.

• .bss -> .section

  legacy TI-syntax

  .bss <symbol>, <size>, <alignment>, <offset>
  

  GNU-syntax

           .section .bss, "aw", %nobits
           .p2align <log2(<alignment>)> <subsection number>
  <symbol>:
           .zero    <size>
           <section directive returns assembler to previous section>
  

  Allocate space in an uninitialized section named “.bss” for a specified symbol with a specified size and alignment. In a section directive, the name of the base section can be annotated with a subsection name. For example, you might create a section name “.bss.myvar” for a symbol called “myvar” as follows:

           .text
           nop
           .section .bss.myvar, "aw", %nobits
           .p2align 4
  myvar:
           .zero    8
           .text
           nop
  

  Alternate GNU-syntax

           .bss <subsection number>
           .p2align <log2<alignment>)> <subsection number>
  <symbol>:
           .zero    8
           <section directive returns assembler to previous section>
  

  The “.bss” directive is also supported in GNU-syntax, but is less flexible than the “.section” directive in that the “.bss” directive only allows an integer value to be specified as the “.bss” subsection name. For example,

           .text
           nop
           .bss     1
           .p2align 4
  myvar:
           .zero    8
           .text
           nop
  

  creates a “.bss.1” section containing the definition of “myvar”.

• .common -> .comm

  legacy TI-syntax

  .common <symbol>,<size>[,<alignment>]
  

  GNU-syntax

  .comm   <symbol>,<size>[,<alignment>]
  

  The .comm directive will allocate space for a variable in a “common” block as opposed to placing the variable in a section. The compiler uses .comm to define an uninitialized file scope variable. If the same variable is defined and uninitialized in another source file in an application, it will also be defined in a common block and the linker will resolve the definitions in multiple common blocks to a single location in memory.

• .usect -> .section

  legacy TI-syntax

  <symbol> .usect "<section name>", <size>, <alignment>, <offset>
  

  GNU-syntax

           .section <section name>, "aw", %nobits
           .p2align <log2(<alignment>)>
  <symbol>:
           .zero    <size>
           <section directive returns assembler to previous section>
  

  Allocate space in an uninitialized user-named section containing the definition of a specified data object represented by the specified symbol with a specified size and alignment.

• .sect -> .section

  legacy TI-syntax

  .sect "<section name>"[, <rw flag>[, <alloc flag>]]          |
  

  GNU-syntax

  .section <section name>, "<scn_flags>", %progbits
  

  GNU-syntax does not distinguish between initialized sections and uninitialized sections via the mnemonic identifier as legacy TI-syntax does (via .sect and .usect). Instead, the GNU-syntax .section directive uses the optional operands after “section name” to indicate characteristics about the section to assemble subsequent lines into.

  scn_flags - is a string that can contain up to 3 distinct characters:

  ‘a’ - section is allocatable. ‘w’ - section is writable. This is typically used for a section that contains data objects whose values may change during the run of an application. ‘x’ - section is executable. This simply means that the section contains executable code, the section may also include data.

  scn_type - indicates whether or not the section contains data (needs to be loaded). There are two legal type specifications:

  ‘progbits’ - section contains data. This characterizes the section as “initialized”. ‘nobits’ - section contains no data and only occupies space. This characterizes the section as “uninitialized”.

• .data

  legacy TI-syntax and GNU-syntax

  .data
  

  Begin assembling into an initialized section named “.data”.

• .text

  legacy TI-syntax and GNU-syntax

  .text
  

  Begin assembling into an initialized section named “.text”.

4.1.3.3.2. Alignment Directives

• .align -> .align and other alternatives

  legacy TI-syntax and GNU-syntax

  .align <alignment>
  

  Advance the current section program counter to the next specified alignment boundary. The specified alignment boundary operand must resolve to a power of 2.

  Some GNU-syntax alternatives

  .balign[w|l]  <alignment>[,<fill>[,<max skip count>]]
  .p2align[w|l] <exponent>[,<fill>[,<max skip count>]]
  

  The .balign and .p2align directives, like .align, will advance the current section to the next specified alignment boundary (for .palign the alignment boundary is expressed as 2 to the exponent power), but only if the number of bytes to be skipped to get to that boundary is less than or equal to the max skip count. The fill value operand is optional. If specified, it indicates the byte value to be inserted into any padding space that is created by the alignment directive.

4.1.3.3.3. Data-Defining and Alignment Directives

• .[u]byte, .[u]char -> .byte

  legacy TI-syntax variants

  .byte  <value1>[, ... <valueN>]
  .ubyte <value1>[, ... <valueN>]
  .char  <value1>[, ... <valueN>]
  .uchar <value1>[, ... <valueN>]
  

  GNU-syntax

  .byte  <value1>[, ... <valueN>]
  

  Place 8-bit integer encodings of each operand into the current section. Specified expression operands must evaluate to an integer in the range [-127, 255].

• .[u]half, .[u]short -> .hword, .short

  legacy TI-syntax variants

  .half   <value1>[, ... <valueN>]
  .uhalf  <value1>[, ... <valueN>]
  .short  <value1>[, ... <valueN>]
  .ushort <value1>[, ... <valueN>]
  

  GNU-syntax

  .hword  <value1>[, ... <valueN>]
  .short  <value1>[, ... <valueN>]
  

  Place 16-bit integer encodings of each expression operand into the current section. Specified expression operands must evaluate to an integer in the range [-32767, 65535].

• .[u]int, .[u]long, .[u]word -> .int, .long, .word

  legacy TI-syntax variants

  .int   <value1>[, ... <valueN>]
  .uint  <value1>[, ... <valueN>]
  .long  <value1>[, ... <valueN>]
  .ulong <value1>[, ... <valueN>]
  .word  <value1>[, ... <valueN>]
  .uword <value1>[, ... <valueN>]
  

  GNU-syntax

  .int   <value1>[, ... <valueN>]
  .long  <value1>[, ... <valueN>]
  .word  <value1>[, ... <valueN>]
  

  Place 32-bit integer encodings of each expression operand into the current section. Specified expression operands must evaluate to an integer in the range [-2147483647, 4294967295].

• .float and .double

  legacy TI-syntax and GNU-syntax

  .float  <value1>[, ... <valueN>]
  .double <value1>[, ... <valueN>]
  

  GNU-syntax also supports an alternative to .float

  .single <value1>[, ... <valueN>]
  

  The .float and .single directives will place 32-bit IEEE-754 single precision encodings of each floating-point constant operand into the current section.

  The .double directive will place 64-bit IEEE-754 double- precision encodings of each floating-point constant operand into the current section.

• .cstring, .string -> .ascii, .asciz, .string

  legacy TI-syntax variants

  .cstring <expr1>|"<string1>"[, ... <exprN>|"<stringN>"]
  .string  <expr1>|"<string1>"[, ... <exprN>|"<stringN>"]
  

  GNU-syntax variants

  .ascii   "<string1>"[, ... "<stringN>"]
  .asciz   "<string1>"[, ... "<stringN>"]
  .string  "<string1>"[, ... "<stringN>"]
  

  Place 8-bit ASCII encodings of each character from each string operand into the current section. Legacy TI-syntax also allows an operand to be specified as an 8-bit integer constant value.

  The .cstring/.asciz directives differ from the .string/.ascii directives in that the assembler inserts a terminating NUL character (’0’) at the end of each string operand for the .cstring/.asciz directives.

4.1.3.3.4. Space Reserving Directives

• .bes -> .space

  legacy TI-syntax

  <symbol> .bes <size>
  

  GNU-syntax nearly functional equivalent

           .space <size>, 0x0
  <symbol>:
  

  The legacy TI-syntax’s .bes directive reserves size bytes in the current initialized section, filling that space with zeros. If a label is specified, the value assigned to the label symbol will be the address of the last byte reserved by the directive.

  Converting the legacy TI-syntax .bes directive involves both a .space directive and a label definition following the .space directive. Please note, however, that in the GNU-syntax conversion, the value assigned to the label will be one byte past the end of the reserved space as opposed to the address of the last byte in the reserved space as is the case with the .bes directive.

• .space

  legacy TI-syntax

  <symbol>  .space <size>
  

  GNU-syntax

  <symbol>: .space <size>,0x0
  

  As shown here, both the legacy TI-syntax and the GNU- syntax .space directives are functionally equivalent. The directive reserves size bytes in the current initialized section, filling that space with zeros. If a label is specified, the value assigned to the label symbol will be the address of the first byte reserved by the directive.

  Note that in the GNU-syntax version the colon (‘:’) appended to the symbol in the label field is required to have the symbol interpreted as a label.

4.1.3.3.5. Directives that Change the Instruction Type

• .arm, .state32 -> .arm

  legacy TI-syntax and GNU-syntax for .arm

  .arm
  

  legacy TI-syntax supports an alias for .arm

  .state32
  

  GNU-syntax also supports an alias for .arm

  .code 32
  

  The effect of the .arm directive (and its aliases) is to instruct the assembler to interpret instructions that follow the .arm directive as 32-bit Arm instructions.

• .thumb

  legacy TI-syntax and GNU-syntax for .thumb

  .thumb
  

  GNU-syntax also supports an alias for .thumb

  .code 16
  

  The effect of the .thumb directive is to instruct the assembler to interpret instructions that follow the .thumb directive as T32 instructions.

4.1.3.3.6. Copy/Include Directives

• .copy -> .include

  legacy TI-syntax

  .copy    <file>
  

  GNU-syntax nearly functional equivalent

  .include "<file>"
  

  The difference between legacy TI-syntax’s .copy directive and its .include directive is that the .copy directive will display the contents of the referenced file in a generated assembly listing file at the location where the .copy directive occurred in the assembly source, the .include directive does not display the contents of the referenced file in an assembly listing file.

  The GNU-syntax .include directive behaves like the legacy TI-syntax directive and is the only viable alternative for translating a legacy TI-syntax .copy directive into something functionally equivalent. Note that the GNU-syntax .include directive requires that the file operand be enclosed in double-quotes.

• .include

  legacy TI-syntax

  .include <file>
  

  GNU-syntax

  .include "<file>"
  

  The GNU-syntax .include directive behaves like the legacy TI-syntax directive in that they both allow you to include the specified file at a specific point in the assembly source file. Note that the GNU-syntax .include directive requires that the file operand be enclosed in double-quotes.

4.1.3.3.7. Symbol Definition Directives

• .equ, .set

  legacy TI-syntax variants

  <symbol> .equ <value>
  <symbol> .set <value>
  

  GNU-syntax variants

  .equ <symbol>, <value>
  .set <symbol>, <value>
  

  Both the legacy TI-syntax and GNU-syntax versions of the .equ and .set directives are functionally equivalent. They define a symbol and assign it a value. However, the syntax is different. In legacy TI-syntax, the symbol is specified in the label field, and in GNU-syntax, the symbol is specified as the first operand.

4.1.3.3.8. Symbol Linkage/Visibility Directives

• .global

  legacy TI-syntax and GNU-syntax

  .global <symbol1>[, ... <symbolN>]
  

  The .global directive identifies one or more symbols to be externally visible (exported) if defined in this module, or identifies one or more symbols to be accessible to this module (imported) if defined in an external module. Each symbol on the symbol list will be given STB_GLOBAL binding.

• .weak

  legacy TI-syntax and GNU-syntax

  .weak <symbol1>[, ... <symbolN>]
  

  The .weak directive identifies one or more symbols used in the current module that if strongly defined in another module will yield to the strong definition. Symbols specified in the sym_list operand of the .weak directive will be given STB_WEAK binding.

4.1.3.3.9. Conditional Assembly Directives

• .if

  legacy TI-syntax and GNU-syntax

  .if <condition>
  <true block>
  .endif
  

  Assemble the subsequent block of assembly source lines if the specified condition evaluates to a non-zero integer constant at assembly time.

• .elseif -> .elseif

  legacy TI-syntax

  .if <condition1>
  <true block1>
  .elseif <condition2
  <true block2
  .else
  <false block>
  .endif
  

  GNU-syntax

  .if <condition1>
  <true block1>
  .elseif <condition2>
    <true block2>
  .else
    <false block>
  .endif
  

  The legacy TI-syntax assembler supports the .elseif directive, which behaves in assembly language similarly to “else if” in C/C++ source code. It creates an alternate block of assembly lines to be assembled when the condition expression associated with the opening .if directive is 0 and the condition associated with the .elseif directive evaluates to a non-zero integer constant.

  GNU-syntax also supports the .elseif directive. You can get equivalent functionality using a nested .if/.endif as follows:

  .if <condition1>
  <true block1>
  .else
    .if <condition2>
      <true block2>
    .else
      <false block>
    .endif
  .endif
  

• .else

  legacy TI-syntax and GNU-syntax

  .if <condition>
  <true block>
  .else
  <false block>
  .endif
  

  When the condition of the preceding conditional directives evaluate to 0, assemble the block of assembly source lines that follow the .else directive.

• .endif

  legacy TI-syntax and GNU-syntax

  .if <condition>
  ...
  .endif
  

  The .endif directive marks the end of a sequence of one or more conditionally assembled blocks of assembly source lines.

• .if $defined(<symbol>) -> .ifdef <symbol>

  legacy TI-syntax

  .if $defined(<symbol>)
  ...
  .endif
  

  GNU-syntax

  .ifdef <symbol>
  ...
  .endif
  

  Assemble the subsequent block of assembly source lines if the specified symbol is defined.

  Note that the legacy TI-syntax equivalent to GNU-syntax’s .ifdef directive makes use of the $defined operator that is available in the legacy TI-syntax assembler.

• .if !$defined(<symbol>) -> .ifndef <symbol>

  legacy TI-syntax

  .if !$defined(<symbol>)
  ...
  .endif
  

  GNU-syntax

  .ifndef <symbol>
  ...
  .endif
  

  Assemble the subsequent block of assembly source lines if the specified symbol is not defined.

  Note that the legacy TI-syntax equivalent to GNU-syntax’s .ifndef directive makes use of the $defined operator that is available in the legacy TI-syntax assembler.

• .loop/.endloop -> .rept/.endr

  legacy TI-syntax

  .loop <count>
  ...
  .endloop
  

  GNU-syntax

  .rept <count>
  ...
  .endr
  

  The legacy TI-syntax’s .loop and the GNU-syntax’s .rept directive mark the beginning of a sequence of assembly lines to be repeated count times. The end of the sequence is marked by the legacy TI-syntax’s .endloop directive and the GNU-syntax’s .endr directive. The count must evaluate to an integer constant value at assembly time.

4.1.3.3.10. Assembly Macro Related Directives

Information about how to migrate assembly language macros written in legacy TI-syntax to GNU-syntax can be found in the Converting TI-syntax Assembly Macros into GNU-syntax Assembly Macros section.

• .macro

  legacy TI-syntax

  <mname>  .macro [<param1>[, ... <paramN>]]
  

  GNU-syntax

  .macro <mname>[, <param1>[, ... <paramN>]]
  

  Mark the start of a macro definition with a specified name (mname in above examples). Note that in the legacy TI-syntax, the macro name must be specified in the label field, but in GNU-syntax, the macro name is specified as the first operand of the .macro directive.

• .mexit -> .exitm

  legacy TI-syntax

  .mexit
  

  GNU-syntax

  .exitm
  

  The GNU-syntax .exitm directive allows you to exit early from within a current macro definition.

• .endm

  legacy TI-syntax and GNU-syntax

  .endm
  

  The .endm directive marks the end of a macro definition.

4.1.3.3.11. Linker Information Directives

• .bound -> .sym_meta_info (for location)

  legacy TI-syntax

  .bound "<section name>", <address>
  

  GNU-syntax

  .sym_meta_info <symbol>, "location", <address>
  

  Both the armcl and the tiarmclang compilers support the location attribute which allows you, in your C/C++ source file, to indicate the memory address where you would like a function definition or data object to be placed in memory.

  The armcl compiler will generate a .bound directive that will instruct the linker to place a specific section (containing the definition of the function or data object) at a specific address in target memory.

  Similarly, the tiarmclang uses its .sym_meta_info “location” directive to instruct the linker to place a specific symbol, representing a function or data object definition, at a specific address in target memory.

• .retain -> .sym_meta_info or .no_dead_strip

  legacy TI-syntax

  .retain "scn"
  

  GNU-syntax

  .sym_meta_info <sym>,"retain",1
  .no_dead_strip <sym>
  

  The tiarmclang integrated assembler supports two directives that can be used to serve the same purpose as the legacy TI-syntax’s .retain directive. Instead of instructing the linker to retain a specific section, the .sym_meta_info and .no_dead_strip directives instruct the linker to retain the section containing the definition of the identified symbol (sym).

4.1.3.4. TI-Syntax Assembly Directives Without a GNU-Syntax Counterpart

The following legacy TI-syntax directives do not have a functionally equivalent counterpart in the GNU-syntax Arm assembly language. For more information about the legacy TI-syntax directives and what they do, please consult the Arm Assembly Language Tools User’s Guide.

4.1.3.4.1. Absolute Listing Directives

• .setsect

• .setsym

4.1.3.4.2. Assembly Macro Related Directives

• .mlib

• .var

4.1.3.4.3. Assembly Source Debug Directives

• .asmfunc

• .endasmfunc

4.1.3.4.4. Conditional Assembly Directives

• .break

4.1.3.4.5. Data-Defining Directives

• .bits

• .field

4.1.3.4.6. Embedded Compiler Options Directive

• .compiler_opts

4.1.3.4.7. Group Directives

• .group

• .gmember

• .endgroup

4.1.3.4.8. Linker Information Directives

• .label

• .retainrefs

4.1.3.4.9. Object Listing Format Directives

• .drlist

• .drnolist

• .fclist

• .fcnolist

• .length

• .list

• .mlist

• .mnolist

• .nolist

• .option

• .page

• .sslist

• .ssnolist

• .tab

• .title

• .width

4.1.3.4.10. Structure/Union Type Definition Directives

• .cstruct

• .struct

• .endstruct

• .cunion

• .union

• .endunion

• .member

• .tag

• .enum

4.1.3.4.11. Substitution Symbol Manipulation Directives

• .asg

• .define

• .eval

• .unasg

• .undefine

4.1.3.4.12. Symbol Linkage/Visibility Directives

• .def

• .ref

• .symdepend

4.1.3.4.13. User-Defined Diagnostic Directives

• .emsg

• .wmsg

• .mmsg

4.1.3.4.14. Miscellaneous Directives

• .cdecls

• .end

• .newblock