Linux and most systems do not have symlink permissions, but some
systems, including MacOS, do, and creation of the symlink with umask
set to 0777 makes the symlink inaccessible on such systems.
clear umask when making a symlink so that the behavior is uniform.

gawk 5 complains.

the specfile for the wrapper was written assuming output is pie only
if -pie appears on the command line. recent (and older patched)
versions of gcc can be configured to produce pie output by default,
adn when used with such a toolchain, the wrapper linked the wrong
startfiles (crt*) containing pic-incompatible code.
rather than trying to figure out gcc's default, simply always use the
pic-compatible start files.

a register used as an index in the memory destination of a mov
instruction was wrongly interpreted as the destination of the mov.

binary ops like ADD, AND, etc. modify the 2nd operand, not 1st.

fdiv and fmul instructions were wrongly matched by the rules for
integer div and mul instructions, leading to incorrect conclusions
about register values being clobbered.

There is a lot which could be common between i386 and x86_64, but none
of it will be useful for any other arch. These should be useful for
all archs, however.

Some functions implemented in asm need to use EBP for purposes other
than acting as a frame pointer. (Notably, it is used for the 6th
argument to syscalls with 6 arguments.) Without frame pointers, GDB
can only show backtraces if it gets CFI information from a
.debug_frame or .eh_frame ELF section.
Rather than littering our asm with ugly .cfi directives, use an awk
script to insert them in the right places during the build process, so
GDB can keep track of where the current stack frame is relative to the
stack pointer. This means GDB can produce beautiful stack traces at
any given point when single-stepping through asm functions.
Additionally, when registers are saved on the stack and later
overwritten, emit ..cfi directives so GDB will know where they were
saved relative to the stack pointer. This way, when you look back up
the stack from within an asm function, you can still reliably print
the values of local variables in the caller.
If this awk script were to understand every possible wild and crazy
contortion that an asm programmer can do with the stack and registers,
and always emit the exact ..cfi directives needed for GDB to know what
the register values were in the preceding stack frame, it would
necessarily be as complex as a full x86 emulator. That way lies
madness.
Hence, we assume that the stack pointer will _only_ ever be adjusted
using push/pop or else add/sub with a constant. We do not attempt to
detect every possible way that a register value could be saved for
later use, just the simple and common ways.
Thanks to Szabolcs Nagy for suggesting numerous improvements to this
code.