Before the patch, running the GNU tbl(1) preprocessor on the
troff file app.codes.nr would give a warning
$ tbl app.codes.nr >app.codes.nr.2
tbl:app.codes.nr:139: no real data
tbl:app.codes.nr:139: giving up on this table
and the table of suffixes
.z no arguments
.l 16-bit argument
... ...
would be left out of the tbl output.
The new .seek assembler pseudo-op advances the location
counter to a fixed offset within a section --- or to a fixed
address, if the section is a .base'd section. It works
somewhat like the GNU assembler's .org pseudo-op, though
with a hopefully less confusing name.
This pseudo-op lets us avoid having to manually compute the
needed boot sector padding in the pc86 start-up code
plat/pc86/boot.s .
The follows( ) function uses pa->os_lign when determining
whether an output section pa immediately follows another
section pb.
However, emits( ) was not using this alignment information
when laying out and padding the output sections. This seems
to be a bug.
I suspect that mach/arm/cv/cv.c might need a similar fix.
This should fix at least some instances of the "undefined
reference to `LLnc_recover'" error that happens in some
builds (https://github.com/davidgiven/ack/issues/218).
The bug was that genname( ) used a static `namebuf' buffer
and did not properly check for overflow when writing into
it. The result was that the `non_corr' variable was
sometimes overwritten with a non-zero value when it should
be zero, causing bogus results later.
This proposed patch makes genname( ) dynamically allocate
and resize a buffer for holding a target file name.
I also take this chance to fix a typo in correct_prefix().
bug caused by this instruction:
fmove.l fp0,d0
problem was caused by a conflict between the fpu emulator (softfloat) and the compiler.
the emulator implemented this as a purely arithmetic move & conversion,
but the compiler assumed that the result could be interpreted as a logical (ie unsigned) conversion.
rightly or wrongly.
for example, if fp0 contained the value 2576980377.0 which is unsigned integer -1717987328
the emulator would treat this as an integer overflow and move 0x7fffffff (INT_MAX) into d0.
The complier on the other hand would assume that d0 contained 2576980377 (the unsigned value).
I don't know which is correct, but this is my fix for the time being.
