| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
as with recent changes, cc's malloc() could make the hunk pointer
misaligned. in the the compilers, the hunk pointer is used directly
by the lexer with no effort to to keep the hunk pointer aligned.
alloc/malloc still return aligned pointers, but hunk itself can
be on a odd address after allocation of a odd sized amount of bytes.
however, in the linkers, this assumption appears to be differnet. as
most allocations mostly allocate padded structures. however, symbol
lookup allocates strings on byte-size ganularity and the cc's malloc
would misalign the hunk pointer after the malloc() call. while the
rest of the code assumed hunk pointer was always aligned.
this change removes all the hunk pointer fiddling from the linker,
and we just call malloc() (which will use the fast implmenentation
of cc, and should not really make much of a performance difference).
|
|
|
|
for gethunk() to work, all allocators have to use it,
including allocations done by libc thru malloc(),
so the fake allocation functions are mandatory for
everyone.
to avoid duplication the code is moved to cc/compat
and prototypes provided in new cc/compat.h header.
|
|
the assemblers share gethunk() cc/macbody but are compiled
without compat.c, so calls such as getenv() trigger malloc()
which does its own sbrk() calls, breaking the continuity
of the hunk.
so this change needs another revision. until then, this is
backed out.
|
|
the compilers and linkers use ther own memory allocator.
free memory is between hunk and hunk+nhunk. allocation
works by checking if nhunk is bigger or equal to the
amount needed, and if not, repeatedly call gethunk()
until there is. after that, the allocated amount is added
from hunk and subtracted from nhunk by the user.
the problem was when the needed amount was bigger than
the default NHUNK size gethunk() allocates per call.
gethunk() would not actually grow nhunk, but instead
just set hunk and nhunk variables to the last allocated
block. this resulted in a infinite loop of calls to
gethunk() until sbrk() would hit the maximum size for
the BSS segment.
this change makes gethunk() actually grow the hunk space,
increasing nhunk, and only updating hunk when nhunk was
previously zero. we assume that mysbrk() retuns increasing
addresses and that the space between the previous hunk+nhunk
and the new block base returned by mysbrk() is usable.
|
|
|
|
|
|
|
|
|
|
|
