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 causes clang to give fewer warnings of implicit declarations of
functions.
In mach/pdp/cv/cv.c, rename wr_int2() to cv_int2() because it
conflicts with wr_int2() in <object.h>.
In util/ack, rename F_OK to F_TRANSFORM because it conflicts with F_OK
for access() in <unistd.h>.
This relocation is specific to PowerPC. @davidgiven suggested the
name RELOPPC_LIS in
https://github.com/davidgiven/ack/pull/52#issuecomment-279856501
Reindent the list in h/out.h and util/led/ack.out.5 because
RELOLIS_PPC is a long name. I use spaces and no tabs because the tabs
looked bad in the manual page.
The new relocation type RELOLIS handles these instructions:
lis RT, ha16[expr] == addis RT, r0, ha16[expr]
lis RT, hi16[expr] == addis RT, r0, hi16[expr]
RELOLIS stores a 32-bit value in the program text. In this value, the
high bit is a ha16 flag, the next 5 bits are the target register RT,
and the low bits are a signed 26-bit offset. The linker replaces this
value with the lis instruction.
The old RELOPPC relocated a ha16/lo16 or hi16/lo16 pair. The new
RELOLIS relocates only a ha16 or hi16, so it is no longer necessary to
have a matching lo16 in the next instruction. The disadvantage is
that RELOLIS has only a signed 26-bit offset, not a 32-bit offset.
Switch the assembler to use RELOLIS for ha16 or hi16 and RELO2 for
lo16. The li32 instruction still uses the old RELOPPC relocation.
This is not the same as my RELOPPC change from my recent mail to
tack-devel (https://sourceforge.net/p/tack/mailman/message/35651528/).
This commit is on a different branch. Here I am throwing away my
RELOPPC change and instead trying RELOLIS.
This commit slightly improves the formatting of the manuals. My
OpenBSD machine uses mandoc(1) to format manuals. I check the manuals
with `mandoc -T lint` and fix most of the warnings. I also make
other changes where mandoc didn't warn me.
roff(7) says, "Each sentence should terminate at the end of an input
line," but we often forgot this rule. I insert some newlines after
sentences that had ended mid-line.
roff(7) also says that blank lines "are only permitted within literal
contexts." I delete blank lines. This removes some extra blank lines
from mandoc's output. If I do want a blank line in the output, I call
".sp 1" to make it in man(7). If I want a blank line in the source,
but not the output, I put a plain dot "." so roff ignores it.
Hyphens used for command-line options, like \-a, should be escaped by
a backslash. I insert a few missing backslashes.
mandoc warns if the date in .TH doesn't look like a date. Our manuals
had a missing date or the RCS keyword "$Revision$". Git doesn't
expand RCS keywords. I put in today's date, 2017-01-18.
Some manuals used tab characters in filled mode. That doesn't work.
I use .nf to turn off filled mode, or I use .IP in man(7) to make the
indentation without a tab character.
ack(1) defined a macro .SB but never used it, so I delete the
definition. I also remove a call to the missing macro .RF.
mandoc warns about empty paragraphs. I deleted them. mandoc also
warned about these macro pairs in anm(1):
.SM
.B text
The .SM did nothing because the .B text is on a different line. I
changed each pair to .SB for small bold text.
I make a few other small changes.
---snip---
The ELF spec at http://www.sco.com/developers/gabi/ says, "In each
symbol table, all symbols with STB_LOCAL binding precede the weak and
global symbols," and that sh_info is the index of the first non-local
symbol.
I was mixing local and global symbols and setting sh_info to zero. I
also forgot to set the type of the .shstrtab section.
---snip---
Convert each ack.out symbol to ELF, preserving its name and value, and
some but not all other symbol info. The ELF symbol table comes with
ELF section headers. If the input file has no symbols (ack -Rled-s),
then the output file has no ELF section headers.
Append the symbol table and section headers to the ELF file. Linux
ignores this appended info when it execs the file. The info might
pollute the last page of the ELF segment, but Linux clears this
pollution. Tools like nm and gdb can read the ELF symbol table.
I include code to translate debugger symbols to an ELF .stab section.
I did not test this code, because I did not find a platform that can
put S_STB symbols in the ack.out file.
Put end of sentence at end of line. This is roff(7) syntax so the
formatter can make spacing between sentences.
Use the macro .PP to break paragraphs. Use bold for the command name
in SYNOPSIS, to match other ack manuals.
calculated incorrectly because of overflow errors.
Replace it with an extended RELOPPC relocation which understands addis/ori
pairs; add an la pseudoop to the assembler which generates these and the
appropriate relocation. Make good.
--HG--
branch : dtrg-experimental-powerpc-branch
directories --- wrangling descr files was too hard. C programs can be built
for cpm, pc86, linux386, linux68k!
--HG--
branch : dtrg-buildsystem
rename : util/ack/build.mk => util/led/build.mk
rename : util/LLgen/build.mk => util/topgen/build.mk
Copy rhead() and rsect() from aslod to aelflod, so aelflod can work
for machine with 64-bit long.
In aelflod, fix ELF header so file(1) no longer reports "corrupted
section header size".
rhead() and rsect() had assumed sizeof(long) == 4, but OpenBSD/amd64
has sizeof(long) == 8. The problem revealed itself when sect->os_lign
became zero, and align() divided by zero.
These files "magically reappeared" after the conversion from CVS to
Mercurial. The old CVS repository deleted these files but did not
record *when* it deleted these files. The conversion resurrected these
files because they have no history of deletion. These files were
probably deleted before year 1995. The CVS repository begins to record
deletions around 1995.
These files may still appear in older revisions of this Mercurial
repository, when they should already be deleted. There is no way to fix
this, because the CVS repository provides no dates of deletion.
See http://sourceforge.net/mailarchive/message.php?msg_id=29823032
