Re: llvm10 build failure on Rpi3

On 2021-Jun-25, at 20:52, bob prohaska <fbsd at www.zefox.net> wrote:

> On Fri, Jun 25, 2021 at 07:52:32PM -0700, Mark Millard wrote:
> [huge snip, hope the quotes are still correct]
>>> So I'm going to suggest using an official kernel build
>>> as built by the ci.freebsd.org systems, one that is not
>>> GENERIC-MMCCAM. In:
>>> 
> 
> World and kernel are updating now to -current as of yesterday.
> I'll replace GENERIC-MMCCAM with GENERIC for simplicity.

I still strongly recommend doing some testing of
official builds instead of your personal builds.
That includes kernel and world, if possible.

Until an official build shows the problem, you
are not as likely to get the problem worked on.

(And, so far, you have the only known context for
getting the problem.)

>>> 
>>> I gather that no RPi4B is available to move the media
>>> to? (Having more RAM but being able to force much of
>>> it to be ignored can be handy as a test environment
>>> for this kind of context.)
>>> 
> 
> It's still patiently chewing away at www/chromium single-threaded.

Note that system-clang just got updates for stable/11 stable/12
stable/13 and main for a defect that prevents building
www/chromium with a clang that has assertions enabled (a form
of debug build contribution):

The branch main has been updated by dim:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=e7e517981a6591c79fb49cd8810361b0f3ad5983


commit e7e517981a6591c79fb49cd8810361b0f3ad5983
Author:     Dimitry Andric <dim at FreeBSD.org>
AuthorDate: 2021-06-21 18:46:34 +0000
Commit:     Dimitry Andric <dim at FreeBSD.org>
CommitDate: 2021-06-21 18:48:37 +0000

    Fix clang assertion while building recent www/chromium
    
    Merge commit c8227f06b335 from llvm git (by Arthur Eubanks):
    
      [clang] Don't assert in EmitAggregateCopy on trivial_abi types
    
      Fixes PR42961.
    
      Reviewed By: rnk
    
      Differential Revision: 
https://reviews.llvm.org/D97872

    
    PR:             256721, 255570
    Reported by:    jbeich
    MFC after:      3 days
---
 contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp b/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp
index 60ea1b2af037..f3ab91559d30 100644
--- a/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp
+++ b/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp
@@ -2056,7 +2056,7 @@ void CodeGenFunction::EmitAggregateCopy(LValue Dest, LValue Src, QualType Ty,
               Record->hasTrivialCopyAssignment() ||
               Record->hasTrivialMoveConstructor() ||
               Record->hasTrivialMoveAssignment() ||
-              Record->isUnion()) &&
+              Record->hasAttr<TrivialABIAttr>() || Record->isUnion()) &&
              "Trying to aggregate-copy a type without a trivial copy/move "
              "constructor or assignment operator");
       // Ignore empty classes in C++.

> My mistake, but best to finish what's started.. Now that how to
> use the packages created is known they can be tested. 
> 
>> 
>> So: no warning about being mis-tuned vs. the 1 GiByte of
>> used RAM. (I do not know about your context for this.)
>> 
> 
> My Pi3 does report too much swap. But I remain uncertain about
> the practical significance of the warning. I gather the issue
> is that a certain amount memory is set aside to "index", for
> lack of a better word, the data stored in swap. If there's too
> much swap relative to index, not all swap can be used. That
> seems not much different than running out of swap. 

You are having problems that are hard to issolate and are also
effectively asserting this warning does not indicate an issue
that is contributing. If it were me, I'd be trying to find out
if the failure can be reproduced when the FreeBSD test involved
classifies that no warning is appropriate.

>> All the ports that devel/llvm10 needs are already in place
>> for poudriere's use for this experiment.

I should have mentioned that I have not added any junk:???
controls.

And my building in a releng/13 context means that 0xA5A5A5A5u
would not be happening on allocation. Stronger: the build
context uses my typical forced MALLOC_PRODUCTION style of build.

>> Another point is:
>> 
>> # more /usr/local/etc/poudriere.d/options/devel_llvm10/options 
>> # This file is auto-generated by 'make config'.
>> # Options for llvm10-10.0.1_3
>> _OPTIONS_READ=llvm10-10.0.1_3
>> _FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD
>> OPTIONS_FILE_SET+=BE_AMDGPU
>> OPTIONS_FILE_SET+=CLANG
>> OPTIONS_FILE_SET+=DOCS
>> OPTIONS_FILE_SET+=EXTRAS
>> OPTIONS_FILE_SET+=LIT
>> OPTIONS_FILE_SET+=LLD
>> OPTIONS_FILE_SET+=LLDB
>> OPTIONS_FILE_SET+=LLD_LINK
>> OPTIONS_FILE_SET+=OPENMP
>> OPTIONS_FILE_UNSET+=PYCLANG
>> OPTIONS_FILE_UNSET+=BE_FREEBSD
>> OPTIONS_FILE_SET+=BE_NATIVE
>> OPTIONS_FILE_UNSET+=BE_STANDARD
>> 
>> (So I normally build less than BE_STANDARD or
>> BE_FREEBSD would build.)
> 
> I'm my own worst enemy when it comes to customization.
> The less changed the better 8-)

Unless it avoids a problem? (I do it to avoid wasted
time.) I'm not claiming it would avoid the problem,
but it is one of the things that could be tried to
see what happens.

>> We will see if this is enough common context to
>> replicate the general type of build problem.
>> (Your details very from one attempt to the next
>> so an exact match need not be expected, even if
>> if this does also fail.)
>> 
> 
> If you replicate the problem I'll be very pleased.
> And just slightly relieved.
> 
> My suspcions still center around  things I might have 
> done to corrupt /usr/local/poudriere.

Poudriere is not involved in initializing memory for
llvm-tblgen's internal memory use.

It could be that jails more generally have a problem,
not just poudriere ones. But that would be a FreeBSD
issue, not a poudriere one.

> That leaves
> me wondering how to proceed after world, kernel and ports
> are updated. Delete /usr/local/poudriere (which would toss
> the packages created so far), delete only the jail (not
> sure if that'll delete existing packages library) or 
> something more selective that I don't know about? 

I see no likely gain from going down this path. Blaming
poudriere for lack of memory initialization in llvm-tblgen
makes no sense to me at all: poudriere is not involved
in that memory allocation or what the bytes are set to
before llvm-tblgen get the address of the memory.

> The Pi3B is purely experimental, but I'd rather not throw 
> away usable progress given the extreme slowness of that
> progress. 
> 



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)