This commit reduces the size of the emitted rebase sections by
generating the REBASE_OPCODE_DO_REBASE_ADD_ADDR_ULEB and
REBASE_OPCODE_DO_REBASE_ULEB_TIMES_SKIPPING_ULEB opcodes.
With this change, chromium_framework's rebase section is a 40% smaller
197 kilobytes, down from the previous 320 KiB. That is 6 KiB smaller
than what ld64 produces for the same input.
Performance figures from my M1 Mac mini:
x before + after N Min Max Median Avg Stddev x 10 4.2269349 4.3300061 4.2689675 4.2690016 0.031151669 + 10 4.219331 4.2914009 4.2398136 4.2448277 0.023817308 No difference proven at 95.0% confidence
nit 1: "flush" is typically used in conjunction with a buffer. Which RebaseState kind of is, so flushRebase seems reasonable, but flushIncrement isn't really flushing anything. How about emitIncrement?
nit 2: "addend" is already used in the context of relocations. How about calling the parameter incr instead, since we are already using it for the function name?