d0p1/ack
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Adapted to current situation

Browse source
This commit is contained in:
ceriel 1987-01-29 13:20:23 +00:00
parent bc8229b952
commit 3d00f0ea37
1 changed files with 4 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
util/led/WRONG
View file

@ -3,10 +3,12 @@ Robbert and Ed found while making the linker usable for the 68000 and amoeba.
I (Ceriel Jacobs) took the liberty of removing the ones that I fixed from I (Ceriel Jacobs) took the liberty of removing the ones that I fixed from
this list. this list.
...
Another problem form the commons: Another problem form the commons:
1 - Local commons are not handled by led and not produced by as.
Must, and will be handled by as. ...
2 - The commons are allocated at the very end of the first pass, after the 2 - The commons are allocated at the very end of the first pass, after the
initialezed data has been allocated in the segments. The order on which initialezed data has been allocated in the segments. The order on which
the commons are allocated seems to be random. That way it is impossible the commons are allocated seems to be random. That way it is impossible
@ -15,11 +17,3 @@ Another problem form the commons:
The currently used trick is to declare an extra segment after the The currently used trick is to declare an extra segment after the
segment containing the commons. The first bytre in this segment segment containing the commons. The first bytre in this segment
inmediatly follows the commons and can be used as _end or endbss. inmediatly follows the commons and can be used as _end or endbss.
The archiver (aal) with the automatic ranlib is buggy.
The only thing that seems to work at the moment is creation of a fresh
archive.
replacing/adding/deleting modules is likely to produce libraries
with incorrect ranlib entries.
The major troublemaker seems to be the extra padding byte at the end
of odd sized modules.