• The assembler parser is modified to parse the new directives and emit appropriate commands to streamers.
• The assembly streamer (used for printing out disassembly) is modified to emit textual directives back from streamer commands.
• The object streamers are modified to act upon the bundling commands to affect the assembly process.
• Note: at this point support has only been added to the ELF object streamer. This is done to answer the immediate needs of NaCl and to reduce the complexity of the initial patch. At a later point, bundling support can also be added to the MachO and COFF streamers, if someone is interested.
• The main assembler logic is modified to support bundling.

1. Parse bundling directives and emit a sequence of sections (MCSectionData) and fragments (MCFragment derivatives) that represent the input. 
2. Perform layout of the fragments to be valid w.r.t. relaxation and bundling.
3. Write the output object.

Parsing and emitting sections and fragments

• A BundleAlignSize field is added to MCAssembler. When the .bundle_align_mode directive is parsed, this field is populated with the bundle alignment size (2 to the power of the argument of .bundle_align_mode). Setting this field is currently allowed once per assembly file. Subsequent .bundle_align_mode directives will be rejected as errors.
• The following state fields are added to MCSectionData and managed by the code parsing .bundle_lock and .bundle_unlock:
• BundleLockState: keeps track of whether the currently parsed code is in a bundle-locked group (between .bundle_lock and .bundle_unlock directives) and whether the group has to be aligned to bundle end.
  
• BundleGroupBeforeFirstInst: keeps track of whether the next instruction parsed will be the first in a bundle-locked group.
• Turned on when .bundle_lock is encountered
• Turned off when an instruction is emitted in the streamer

• All instructions are emitted into separate fragments (either data or instruction fragments, depending on whether they are candidates for relaxation). This is essential because each instruction may potentially need to be padded to obey bundling rules when layout is performed (details below). Bundling does not apply to non-instructions like data, alignment directives, etc.
• Instructions in bundle-locked groups get emitted into the same data fragment, since they are all part of the same group which has to be moved and padded together.
• To make this possible, all potentially relaxable instructions inside bundle-locked groups are relaxed before emission, so that they won't need relaxation in the future.
• While in theory the above means the code can become larger than necessary, in practice instructions actually requiring relaxation won't usually appear in bundle-locked groups, so the practical cost is very low. The gain is a significant simplification of the implementation.

Laying out fragments

• When layout on a fragment is performed, the fragment's offset and size are computed.
• The following steps apply only if:
• Bundling is enabled
• The fragment contains instructions (we don't pad data and alignment fragments)
• For this purpose, a boolean predicate hasInstructions is added to MCFragment
• If it's determined that the fragment will cross a bundle boundary, padding is required.
• The required amount of padding is computed and stored in the BundlePudding field of the fragment.
  This field is restricted to uint8_t, in order to save space in the mainstream case (bundling disabled). In practice, fragments of larger size will not be encountered (bundling is done at most on small groups of a few instructions).
• The fragment offset is set to point after the padding, at the start of the actual fragment. This way the following invariant still holds:
  fragment offset + fragment size = offset of next fragment
  
• Padding is also required if the align_to_end option is provided to a bundle-locked group.