On 4/19/24 10:27, Paul Smith wrote:
On Fri, 2024-04-19 at 09:54 -0400, Dennis Clarke via Bug reports and
discussion for GNU make wrote:
Where does one even begin to discover where something ( everything? )
went so horribly wrong?
The very first thing you should try is re-configuring GNU Make without
any special flags (unset CFLAGS) and re-run configure from scratch and
see if that build works better.
Thank you for the quick reply.
Good idea. I figure that another approach would be to change just a few
things and give it a whirl ... with excellent results :
$ echo $CFLAGS
-m64 -g -O0 -march=k8 -mtune=k8 -fomit-frame-pointer -fstrict-aliasing
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags
$
.
. a cup of coffee later
.
1442 Tests in 134 Categories Complete ... No Failures :-)
=======================================================================================
Regression PASSED: GNU Make 4.4.1 (x86_64-unknown-netbsd10.0) built
with /usr/bin/gcc
=======================================================================================
Neato.
As far as I can tell the problem is because you're including this:
-fno-builtin
Yep. The calls to alloca() seem to be all over the place in the code
base and I can not figure out why anyone would want a non-portable and
non-standard thing like that but here we are.
in your CFLAGS. I'm not sure why you want to do that, but I recommend
removing that, at least. I don't actually know exactly why that causes
a problem but it's completely clear from the test results that the
problems you're having are due to bad memory which means I agree with
you it's due to this alloca mismatch/issue. I can't say why the
problem happens: either GCC's handling of -fno-builtin has an issue or
else the configure script's detecting of the situation is not working
correctly.
There are a number of reasons to disable the GCC compilers dirty little
tricks where it will replace things like "printf" with "puts". At the
very least it is really tough to explain to a student trying to debug
some trivial code when they see strange things appear in the assembly
when the post processed intermediate code calls for a "printf". So I
have had great success with the -fno-builtin option in many many places.
That includes the libgmp and libmpfr codebase.
So now I will go digging around and see why alloca() is being used all
over the GNU Make code. There must be a valid reason for that stuff. I
can tell you the manpage for ALLOCA(3) on NetBSD is just nasty :
io# man alloca
man: Formatting manual page...
ALLOCA(3) Library Functions Manual ALLOCA(3)
NAME
alloca – memory allocator
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include <stdlib.h>
void *
alloca(size_t size);
DESCRIPTION
The alloca() function allocates size bytes of space in the stack
frame of the caller. This temporary space is automatically freed
on return.
RETURN VALUES
The alloca() function returns a pointer to the beginning of the
allocated space. If the allocation failed, a NULL pointer is
returned.
SEE ALSO
cc(1), brk(2), calloc(3), getpagesize(3), malloc(3), realloc(3),
security(7)
CAVEATS
Few limitations can be mentioned:
• The alloca() function is not part of any C standard and its use
is not portable.
• The alloca() function should be supplied by the compiler
because the compiler is allowed to make assumptions about the
stack and frame pointers. The libc alloca() implementation
cannot account for those assumptions. While there is a machine
dependent implementation of alloca() in libc, its use is
discouraged and in most cases it will not work. Using this
implementation will produce linker warnings.
• The alloca() function is unsafe because it cannot ensure that
the pointer returned points to a valid and usable block of
memory. The allocation made may exceed the bounds of the
stack, or even go further into other objects in memory, and
alloca() cannot determine such an error. For that all alloca()
allocations should be bounded and limited to a small size.
• Since alloca() modifies the stack at runtime and the stack
usage of each function frame cannot be predicted, it makes many
compiler security features (such as cc(1) -fstack-protector)
useless for the calling function. See security(7) for a
discussion.
NetBSD 10.0 October 24, 2012 NetBSD 10.0
Yep. Those warnings in the "CAVEATS" section are pretty scary. Really a
convenient way to toss malloc/calloc over one's shoulders and just give
up on tracking what was allocated on the heap. Convenient. Ugly.
I will mess around further with some compiler options but for now the
thing compiles and tests clean. I may have to accept that this is what
it is for now.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken