add support for more prettiness features in the hex-transform's output

suffix comments can now have a negative length, which makes them cover a span anchored with the current point at its end rather than its start

magic comments can now request the suppression of metadata entries that would otherwise be generated

everything in elf.e has magic comments now

Force-Push: yes
Change-Id: I409982afdd346c2ecf91e4c24f96ca81f887b126

1 files changed, 60 insertions, 39 deletions

diff --git a/elf.e b/elf.e
index a149a0f..82af2f5 100644
--- a/elf.e
+++ b/elf.e
@@ -8,6 +8,10 @@
 ~
 ~   This relies on the label facility defined in labels.e. Make sure to load
 ~ that first.
+~
+~   This file makes use of magic comments for the hex transform, described in
+~ detail in transform.e, but its use is trivial and doesn't require accounting
+~ conventions.
 
 ~ ~~~~~~~~~~~~~~~~~~~~~
 ~ ~~ ELF file header ~~
@@ -25,40 +29,47 @@
 : elf-file-header
   ~ : blank-line
   ~ : ELF file header
-  ~ * denotes mandatory fields according to breadbox
+  ~ : indent
+  ~ : * denotes mandatory fields according to breadbox
   current-offset 3unroll
 
-  0x7f pack8 s" ELF" pack-raw-string    ~ *magic number
-  2 pack8                               ~ 64-bit
-  1 pack8                               ~ little-endian
-  1 pack8                               ~ ELF header format v1
-  0 pack8                               ~ System-V ABI
-  0 pack64                              ~ (padding)
+  ~ : 1 suppress
+  0x7f pack8 s" ELF" pack-raw-string  ~ : -4 *magic number
+  2 pack8                             ~ : -1 64-bit
+  1 pack8                             ~ : -1 little-endian
+  1 pack8                             ~ : -1 ELF header format v1
+  0 pack8                             ~ : -1 System-V ABI
+  0 pack64                            ~ : -8 (padding)
+  ~ : blank-line
 
-  2 pack16                              ~ *executable
-  0x3e pack16                           ~ *Intel x86-64
-  1 pack32                              ~ ELF format version
+  2 pack16                            ~ : -2 *executable
+  0x3e pack16                         ~ : -2 *Intel x86-64
+  1 pack32                            ~ : -4 ELF format version
+  ~ : blank-line
 
-  L@' cold-start L@' origin + pack64        ~ *entry point
+  L@' cold-start L@' origin + pack64  ~ : -8 *entry point
     ~ This includes the origin, intentionally.
 
-  L@' elf-program-header pack64         ~ *program header offset
+  L@' elf-program-header pack64       ~ : -8 *program header offset
     ~ We place the program header immediately after the ELF header. This
     ~ offset is from the start of the file.
-  0 pack64                              ~ section header offset
-  0 pack32                              ~ processor flags
+  0 pack64                            ~ : -8 section header offset
+  0 pack32                            ~ : -4 processor flags
+  ~ : blank-line
 
-  L@' elf-header-size pack16            ~ ELF header size
-  L@' elf-program-header-size pack16    ~ *program header entry size
-  1 pack16                              ~ *number of program header entries
-  0 pack16                              ~ section header entry size
-  0 pack16                              ~ number of section header entries
-  0 pack16                              ~ section name string table index
+  L@' elf-header-size pack16          ~ : -2 ELF header size
+  L@' elf-program-header-size pack16  ~ : -2 *program header entry size
+  1 pack16                            ~ : -2 *number of program header entries
+  0 pack16                            ~ : -2 section header entry size
+  0 pack16                            ~ : -2 number of section header entries
+  0 pack16                            ~ : -2 section name string table index
 
   ~   Though hardcoding the size of this header would work fine, it's easier
   ~ to use the label system to keep track of its size. The only place this is
   ~ actually referenced is right here in the header.
-  current-offset 4 roll - L!' elf-header-size ;
+  current-offset 4 roll - L!' elf-header-size
+  ~ : deindent
+  ;
 
 
 ~ ~~~~~~~~~~~~~~~~~~~~~~~~
@@ -90,26 +101,31 @@
 : elf-program-header
   ~ : blank-line
   ~ : ELF program header
+  ~ : indent
   ~ * denotes mandatory fields according to breadbox
   current-offset L!' elf-program-header
   current-offset 3unroll
 
-  1 pack32                              ~ *"loadable" segment type
-  0x05 pack32                           ~ *read+execute permission
-  0 pack64                              ~ *offset in file
-  L@' origin pack64                     ~ *virtual address
+  1 pack32                            ~ : -4 *"loadable" segment type
+  0x05 pack32                         ~ : -4 *read+execute permission
+  0 pack64                            ~ : -8 *offset in file
+  L@' origin pack64                   ~ : -8 *virtual address
     ~ required, but can be anything, subject to alignment
-  0 pack64                              ~ physical address (ignored)
+  0 pack64                            ~ : -8 physical address (ignored)
+  ~ : blank-line
 
-  L@' total-size pack64                 ~ *size in file
-  L@' total-size pack64                 ~ *size in memory
+  L@' total-size pack64               ~ : -8 *size in file
+  L@' total-size pack64               ~ : -8 *size in memory
+  ~ : blank-line
 
-  0 pack64                              ~ segment alignment
+  0 pack64                            ~ : 8 segment alignment
     ~ for relocation, but this doesn't apply to us
 
   ~   As with the file header, we use the label system to keep track of the
   ~ program header's size.
-  current-offset 4 roll - L!' elf-program-header-size ;
+  current-offset 4 roll - L!' elf-program-header-size
+  ~ : deindent
+  ;
 
 
 ~   This alternate version of the program header isn't used by evoke.e, but
@@ -118,26 +134,31 @@
 : elf-program-header-writable
   ~ : blank-line
   ~ : ELF program header
+  ~ : indent
   ~ * denotes mandatory fields according to breadbox
   current-offset L!' elf-program-header
   current-offset 3unroll
 
-  1 pack32                              ~ *"loadable" segment type
-  0x07 pack32                           ~ *read+write+execute permission
-  0 pack64                              ~ *offset in file
-  L@' origin pack64                     ~ *virtual address
+  1 pack32                            ~ : -4 *"loadable" segment type
+  0x07 pack32                         ~ : -4 *read+write+execute permission
+  0 pack64                            ~ : -8 *offset in file
+  L@' origin pack64                   ~ : -8 *virtual address
     ~ required, but can be anything, subject to alignment
-  0 pack64                              ~ physical address (ignored)
+  0 pack64                            ~ : -8 physical address (ignored)
+  ~ : blank-line
 
-  L@' total-size pack64                 ~ *size in file
-  L@' total-size pack64                 ~ *size in memory
+  L@' total-size pack64               ~ : -8 *size in file
+  L@' total-size pack64               ~ : -8 *size in memory
+  ~ : blank-line
 
-  0 pack64                              ~ segment alignment
+  0 pack64                            ~ : -8 segment alignment
     ~ for relocation, but this doesn't apply to us
 
   ~   As with the file header, we use the label system to keep track of the
   ~ program header's size.
-  current-offset 4 roll - L!' elf-program-header-size ;
+  current-offset 4 roll - L!' elf-program-header-size
+  ~ : deindent
+  ;
 
 ~ ~~~~~~~~~~~~~~~~
 ~ ~~ That's it! ~~