The code for handling archives is not widely used. Therefore it does
not need to be fast. Clarity of the code is more important. Therefore
replace the malloc + strlen + realloc + snprintf string processing with
the Buffer type, which removes a lot of redundancy.
In the wildcard loop, the "if (sz > nsz)" looked like a mistake. Why
should it be useful to first allocate a large buffer and then resize it
to a smaller buffer, but still twice as large as necessary?
Costs another couple MOV instructions, but we can't skimp on this --
there's no red zone below sp for interrupts on arm, so we can't touch
anything there. So just use fp to save sp and then adjust sp itself,
rather than using fp as a temporary register to point just below sp.
Should fix PR port-arm/55598 -- previously the ChaCha self-test
failed 33/10000 trials triggered by sysctl during running system;
with the patch it has failed 0/10000 trials.
(Presumably it happened more often at boot time, leading to 5/26
failures in the test bed, because we just enabled interrupts and some
devices are starting to deliver interrupts.)
Lst is an untyped list of pointers. During debugging, it is often
necessary to inspect the content of the list. To do this without manual
typecasting, add a few aliases for the LstNode.datum pointer, for
inspecting GNodes and strings.
GNode.commands is the only place in make where a list can contain null
pointers. That's unexpected, and memory management in CompatRunCommand
looks suspicous enough to warrant extensive documentation.
the logic for setting the USPACE size. Define a desired USPACE size
(16kB for LP64, 8kB otherwise) then divide by PAGE_SIZE to get UPAGES.
Fixes random segmap lossage, since the uarea usually sits immediately
above the segmap for a process. Thanks to mrg@, skrll@ and dholland@
for testing, debugging and general help tracking down this problem.
Theoretically this should show the enum constant names when displaying
the field in the debugger. This only happens for GNode.flags though,
but not for GNode.type. Not sure what the exact cause is.
The compiler had unrolled this loop anyway, and for humans it is more
readable as well.
The comments "must be first" and "must be second" came from a time when
the variables were stored in a linked list instead of a hash table.
Maybe this "must" was about performance back then. Anyway, the tests
run fine with either order, and there is absolutely no evidence that the
order of these variables could have any effect.
