1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
|
Please report all bugs, errors, or things you'd like to have changed
directly to Steffen.Kaiser@fh-rhein-sieg.de
The following conditions I'm interested in particular:
+ A linker could not found some publics, but does, when the library
is created with another librarian.
Check out the list file if the symbol is listed there. If not,
send me the OBJ file. Otherwise, send me the list file.
+ LLIB caused some strange behaviour because of its different command
line syntax. Tell me why.
The debug files (dbug.*) are Public Domain (see their headers). I alterred
the db_print function to use the "..." syntax and replaced DB_VOID_RETURN
by DB_EXIT and use NDEBUG to determine whether or not to activate the
debug macros. Note: If NDEBUG is not set, the debug macros become active
and the error report goes into the file LIB.ERR. LLIB logs all calls to
malloc(), free(), realloc(),& strdup(); the by-packed perl script TST_MEM.PL
checks the error report for invalid calls. It assumes that the line prefix
consists only of file name, line number, and nesting level.
Information:
In order to compiler LLIB you'll need the message library and the
supplemental library (either prepared or in source text).
The first one is available as: MSGLIB2.ZIP
The second one as: SUPPL22.ZIP
To use the Makefile you'll need the additional STARTUP.MK, FD_INIT.MK,
FD_EXIT.MK and the DMAKE patchlevel 2 (modified by myself).
These files should be available in the package: DMAK-SK2.ZIP
The far memory support is hand-made. I choosed this way because the
destination compilers are Micro-C and Borland C++, but Micro-C
does not know about the Compact memory model.
Because of this, the far data memory models of other compilers won't
(I think) coexist with my implementation. More information about that
is available in the source file LIST.C.
The UMBs are not chained into the available memory, because I suppose
that there is not much memory free.
With the far memory support approx. 17,000 items (files in the
current directory and multiply defined symbols) can be handled,
assuming that 500,000 bytes are free.
The module names are also placed in the library directory, with an
appended '!'. This is the behaviour of Borland's TLIB, which is
my only comparative.
With v4.52 this has been changed; the module names are stored
in a name definition record now. LLIB has been fixed to handle
both cases.
While generating the library directory, an informative "Failed.
Recreating ..." might be displayed. This is simply the information,
that the amount of library directory pages had to be increased.
If the '/M' option is NOT given, the module is named after the file
it is stored in (upper-cased name without extension, path,& drive).
Already stored modules are named according the OBJ record.
This is because the original contents varys between the origin
of the OBJ module, e.g. Borland C++ places the source file name
incl. extension there, Arrowsoft assembler always stores "A" there.
That also causes the difference in size when adding & subtracting
the same OBJ module.
If a module name contains a '\0' character, all characters behind
that character become invalid (random, or stripped) unless the '/M'
option is given.
The detection of the optimal page size is a straight forward method by
counting how many pages are necessary to create the library with the
particular page size. Because the optimal page size cannot exceed
the maximal page size, the brute force method (/i=0, or /i=65535)
will check the range from the minimal to the maximal page.
Otherwise, the range is # (/i=#) wide and starts with the minimal
page size.
Don't expect to see too many differences when the library directory
alignment is not disabled (/X option).
Borland sucks. First they surprised my LLIB with the bad Check Sums, then
you enable stack checking, but you will never actually be noticed that
the heap and the stack collides, neither by the run-time code for
stack checking nor by malloc() == 0 nor by checkheap(), then the debugger
sometimes places a (word)0 into the code segments (each time the
debugger shall execute an instruction).
This behaviour caused me to waste much time before I started to
implement the far memory storage for the module name list, thus,
separating the heap, the stack, and the space consuming the name list,
hoping that a memory underrun is more easily detected than by random
crashes; and to add the debug macro package.
|
