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.
problem was implementation of fint & fintrz floating point ops in m68kfpu.c
Both these ops truncated the integer to 32 bits instead of leaving it as an extended precision floating point number
Changed the implementation to use 64 bit ints instead of 32 bit ints.
