Re: llvm10 build failure on Rpi3

On 2021-Jun-23, at 15:28, bob prohaska <fbsd at www.zefox.net> wrote:

> On Wed, Jun 23, 2021 at 02:03:42PM -0700, Mark Millard wrote:
>> On 2021-Jun-23, at 10:43, bob prohaska <fbsd at www.zefox.net> wrote:
>> 
>>> On Wed, Jun 23, 2021 at 01:34:55AM -0700, Mark Millard wrote:
>>>> 
>>>> Not that it helps much, but: 2779096485 == 0xA5A5A5A5
>>>> 
>>>> It appears that such somehow was involved-in/generated by:
>>>> 
>>>> [ 24% 1326/5364] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen -gen-global-isel -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMDGPUGISel.td --write-if-changed -o lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d
>>>> 
>>>> and that lead to the commented out notation in the output, with the "@2779096485" listed in the comment as well.
>>>> 
>>> 
>>> A Pi4 doing a bulk build of chromium, lxqt and apache has gone far past that
>>> point building llvm10, suggesting the fault lies somewhere in my setup.
>> 
>> I'm not so sure of that for the 0xA5A5A5A5u value. You run
>> main [so: 14 at this point]. Is it a debug build? Or a
>> non-debug build? I expect that 0xA5A5A5A5u has some specific
>> debug-build potential meaning.
>> 
> The kernel in use is 
> FreeBSD www.zefox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n247405-8fa5c577de3: Fri Jun 18 17:03:19 PDT 2021     bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-MMCCAM  arm64
> and it can invoke the debugger using [enter]-tilda-control-b.

If it was a normal style build of main-n247405-8fa5c577de3 then
both the kernel and world would be debug builds. But it is
possible to explicitly control if MALLOC_PRODUCTION is used
instead and the like, based on how doing the build was configured.
(Lots more can be controlled for the builds.)

I still can not tell if it was a debug (normal) main build or
not. I would guess it was a normal debug build, no extra
disabling or enabling of such.

Side Note:
Going in a separate direction: do you also run main on faster
aarch64 systems (RPi4B's)? Do you also build there? If so, it
is possible to make a copy of the

poudriere/data/packages/main-default/

tree from the fast system on the slower system and then
use pkg on the slower system without doing builds there.

It is also possible to set up to have the fast system
be used as a remote source of the packages, much like
FreeBSD servers. But I've never done such. Based on
what you have done to publish for folks to look at
when they are helping, you might (mostly?) already
have that set up, other than pointing package to
the right URL on the slower machine.
End Side Note.

>> For example, 0xA5u byte values might be the value that newly
>> allocated memory is initialized to. Looking . . . man jemalloc
>> (the memory allocator implementation used by FreeBSD) reports:
>> 
>>       opt.junk (const char *) r- [--enable-fill]
>>           Junk filling. If set to ???alloc???, each byte of uninitialized
>>           allocated memory will be initialized to 0xa5. If set to ???free???, all
>>           deallocated memory will be initialized to 0x5a. If set to ???true???,
>>           both allocated and deallocated memory will be initialized, and if
>>           set to ???false???, junk filling be disabled entirely. This is intended
>>           for debugging and will impact performance negatively. This option
>>           is ???false??? by default unless --enable-debug is specified during
>>           configuration, in which case it is ???true??? by default.
>> 
>> So, if you have junk filling enabled, I expect that you ran
>> into a legitimate defect in the llvm-tblgen in use. Having
>> Junk Filling disabled might be a workaround.
>> 
>> There is /etc/malloc.conf as a way of controlling the behavior:
>> 
>> ln -s 'junk:false' /usr/local/poudriere/poudriere-system/etc/malloc.conf
>> 
>> I suggest you retry building after getting the above in place.
>> If it does not get the 0xA5A5A5A5u value, that would be
>> more evidence of a uninitialized-memory defect in the llvm-tblgen
>> involved.
>> 
> Done and running now. In the interim I tried building llvm10 using
> make in /usr/ports, but it failed with another python conflict.

Intersting. I'm unable to see a:

/usr/local/poudriere/poudriere-system/etc/malloc.conf

via what you have published. But I've no clue if such
an odd symbolic link would be expected to show up.

>> I do not normally run debug builds and so would not have
>> run into 0xA5A5A5A5u from Junk Filling of memory allocations.
>> 
>> I'm not sure when I can setup and do a junk filling experiment
>> (in a debug main build?). But it looks like some independent
>> compare/contrast activity might be appropriate.
>> 
>>> The instructions you gave for setting up poudriere seemed to work perfectly
>>> initially, but since that time both world and kernel have been updated
>>> along with ports. Is it necessary or advisable to alter /usr/local/poudriere,
>>> either by  update commands or complete replacement? 
>> 
>> I will note that your log file reports:
>> 
>> Host OSVERSION: 1400023
>> Jail OSVERSION: 1400019
>> 
>> So your jail's OSVERSION is older than the environment
>> that it is running in. (Unlikely to contribute to the
>> 0xA5A5A5A5u as far as I can tell.) In other words, you
>> have not updated your:
>> 
>> /usr/local/poudriere/poudriere-system/
>> 
>> to 1400023 as far as I can tell.
>> 
> 
> After one of the world/kernel rebuilds I attempted to repeat your
> poudriere setup instructions, thinking it would update the setup.
> IIRC both commands were refused, not with an error, but more like
> a "don't do that" sort of message. I fumbled for a while with
> poudriere ports -u, but couldn't get the syntax right. Then I
> noticed a reference to null-mounting /usr/ports, which strongly
> suggested any updates to ports would be picked up by default. 

The steps in question for my point are (from your
http://www.zefox.org/~bob/readme ):

# cd /usr/src
# make installworld DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1
# make distrib-dirs DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1
# make distribution DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1

Your:

cd /usr/local/poudriere
# poudriere ports -c -m null -M /usr/ports
# poudriere jail -c -j main -m null -M /usr/local/poudriere/poudriere-system -S /usr/src -v 14.0-CURRENT

leaves /usr/ports/ and /usr/src/ automatically bound to
the most recent content from the system.

But the installworld related material is not automatic.
(And poudriere should not point at the live system's
own materials for such: during operation it temporarily
changes some things in the system it is pointed at.)

>> Separately from that, for poudriere itself:
>> 
> 
>> I do not know if you are using ports-mgmt/poudriere-devel vs.
>> ports-mgmt/poudriere . 
> 
> Poudriere version reports 3.3.6. I believe it's _not_ the -devel version.

Okay. I've always used poudriere-devel . No reason that you
should but now I know that we can have some distinctions
for poudriere itself for recent functionality.

>> But, whichever, it is a port and is
>> one of the ports that should be built when it has updated
>> when you update /usr/ports content and should then have its
>> install be updated via pkg like the other ports.
>> 
> 
> I've yet to master getting pkg to actually work from a local repository.
> The handbook says to create 
> /usr/local/poudriere % more /usr/local/etc/pkg/repos/FreeBSD.conf
> containing
> FreeBSD: {
>        enabled: no
> }

That is part of it. I have:

# find /usr/local/etc/pkg/repos/ -print
/usr/local/etc/pkg/repos/
/usr/local/etc/pkg/repos/FreeBSD.conf
/usr/local/etc/pkg/repos/custom.conf

# more /usr/local/etc/pkg/repos/custom.conf 
custom: {
        url: "file:///usr/local/poudriere/data/packages/13_0R-CA72-default",
        enabled: yes,
}

The file:// prefix is URL notation and the rest is the directory path,
including its leading / . So, for your context:

custom: {
        url: "file:///usr/local/poudriere/data/packages/main-default",
        enabled: yes,
}

I'll note that the default for remote use of the
FreeBSD servers looks like:

# more /etc/pkg/FreeBSD.conf 
# $FreeBSD$
#
# To disable this repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file:
#
#   mkdir -p /usr/local/etc/pkg/repos
#   echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
#

FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}

So something somewhat similar likely could be used in
/usr/local/etc/pkg/repos/custom.conf to use a faster
machine's packages via a slower machine's pkg, without
coying over the directory tree that contains the
respository.

> Hopefully, using 
> pkg install -r /usr/local/poudriere/data/packages/main-default/All [pkgname]
> will do the trick. Any cautionary tales would be much appreciated. 

With an appropriate /usr/local/etc/pkg/repos/custom.conf you
should be able to use pkg normally.

The pkg install -r installs more than needed and not in a way
that pkg autoremove would clean up. When you get pkg working
with /usr/local/poudriere/data/packages/main-default/ material,
you might want to do a round of deleting the installs and
then only explicitly installing the things that you directly
want to use. The rest needed at run-time should automatically
install, but in a way that would allow for a later autoremove
to work for things that are no longer being used after an
update.

>> I list ports-mgmt/poudriere-devel in the file with the other
>> ports that I list in ~/origins/CA72-origins.txt and I use
>> that file via -f in the bulk command.
>> 
> 
> If there's a guide to using poudriere/pkg in a self-hosting situation
> it would be very useful. The existing docs have a very different focus.




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