Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

[Dennis Clarke]

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