Date: Tue, 21 Sep 2021 18:27:13 -0700 From: Mark Millard via freebsd-ports <freebsd-ports@freebsd.org> To: =?utf-8?Q?Lucas_Nali_de_Magalh=C3=A3es?= <rollingbits@gmail.com>, freebsd-ports@freebsd.org Subject: Re: armv7 target (on aarch64 HW) and poudriere-based emulators/mame link failure vs. success based on the number of cores Message-ID: <FC9D07BD-F1B3-40D6-B1AA-499284CC4A0E@yahoo.com> In-Reply-To: <5FC47541-1F8E-4F51-8D98-6AA7AD538D51@yahoo.com> References: <64B80EEA-DECC-4286-AC80-5BE55B7F19D4@yahoo.com> <7EC14B75-654D-45BA-8260-B3D922B81603@gmail.com> <A3FFD4A1-78FE-41B2-BC4C-D0F733AC878D@yahoo.com> <6A5450DA-A50A-4A9F-AC9B-430016F92D50@yahoo.com> <5FC47541-1F8E-4F51-8D98-6AA7AD538D51@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Sep-20, at 17:47, Mark Millard <marklmi@yahoo.com> wrote:
> On 2021-Sep-20, at 15:10, Mark Millard <marklmi at yahoo.com> wrote:
>=20
>> On 2021-Sep-20, at 13:58, Mark Millard <marklmi at yahoo.com> wrote:
>>=20
>>>=20
>>> On 2021-Sep-20, at 12:54, Lucas Nali de Magalh=C3=A3es =
<rollingbits@gmail.com> wrote:
>>>=20
>>>> On Sep 19, 2021, at 6:14 AM, Mark Millard via freebsd-toolchain =
<freebsd-toolchain@freebsd.org> wrote:(=E2=80=A6)
>>>>=20
>>>> (=E2=80=A6)
>>>>=20
>>>> The HoneyComb failure looks to me like like hitting the process
>>>> size limitations for armv7, something that did not happen on the
>>>> MACCHIATObin Double Shot or RPi4B (fewer cores).
>>>>=20
>>>> It looks to me like 32-bit architectures (such as armv7) should
>>>> possibly have the multi-threaded link disabled by default
>>>> for FreeBSD unless ports are adjusted to disable multi-threaded
>>>> individually.
>>>>=20
>>>> (=E2=80=A6)
>>>=20
>>> There are a few a few problems with your analysis: 32 and 64 bit
>>> architectures sizes aren't that small and much of all OSes today
>>> evolved around extending these sizes. This doesn't means that one
>>> can not use all of it but that the analysis requires a little more =
"salt".
>>> So it looks like you used all of something=E2=80=A6 maybe you need =
to adjust
>>> some numbers somewhere.
>>>=20
>>> Then, processes and threads existed far before the existence of
>>> multicore desktop CPUs. Running with more threads/processes than
>>> the number of cores you have only means that some swapping *may be*
>>> necessary. If you have enough RAM, swap isn't really necessary. So I =
think
>>> this makes your suggestion ridiculous.
>>>=20
>>=20
>>=20
>> Sorry: a stray click lead to an accidental send of a reply with
>> no additional content.
>>=20
>>=20
>> The above did not indicate any specific errors for me to
>> fix, experiments to try, or even any specific alternate hypothesis
>> for the inability to allocate in the failing context that I
>> described. So I've no clue of a good way to make any progress from
>> what is written. I see no reason to withdraw the suggestion based
>> on the above. I'm well aware that there are tradeoffs and that
>> the suggestion might not be used even if I've gotten everything
>> correct about the failure's cause.
>>=20
>>=20
>> After the HoneyComb system is done with the bulk -a activity
>> targeting aarch64, I'l likely try bulk -w targeting armv7 in hopes
>> of getting a .core for the failure. That will be days away and the
>> rebuild attempt for emulators/mame will have to rebuild the
>> prerequisite ports (the armv7 packages were deleted before starting
>> the aarch64 targeting builk -a). So even more time.
>=20
> [I discovered that the aarch64 targeting bulk -a would not
> sucessfully build something I wanted in the bulk -a activity.
> So I stopped that build and will restart at some point after
> updating /usr/ports/ to a version that should build that port.]
>=20
> Well, my attempt to build llvm12 with debug info, when targeting
> armv7, did not go well. The intent was so that a backtrace
> of its linker would be useful to me.
>=20
> So this type of experiment proved not useful.
>=20
>> I'd consider other evidence gathering alternatives that might
>> better indicate specifically why the allocation fails in the
>> failing context. But the large nubmer of build steps prior to
>> the failing link and such probably limit the options.
I created a portmamster/Makefile port building context in which
the failing link also occurs, without waiting 11 hr+ for
other parts of mame to build each time after the first. I
established the context with already built prerequeisite packages
that poudriere had aleady made. So only emulators/mame was being
built.
Then I tried adding an LDFLAGS initial definition to control the
threading in that environment to be just one thread:
portmaster -CGKDg -mLDFLAGS=3D-Wl,--threads=3D1 --packages-build =
emulators/mame
The result was:
. . .
gmake[2]: Entering directory =
'/usr/ports/emulators/mame/work/mame-mame0226/build/projects/sdl/mame/gmak=
e-freebsd-clang'
Linking mame...
Compiling src/lib/netlist/prg/nltool.cpp...
. . .
In other words: no more failure for the link that had been failing.
(Note: I was able to see the link command and its --threads=3D1 in
top.)
Simply avoiding having the extra threads allowed the link
to complete --because it needed less memory to be allocated.
The rest of the build completed as well.
Such is important for native builds via poudreire on systems
with many "FreeBSD cpus" for armv7, armv6, and such. I'm
not claiming emulators/maem would be the only example, it
is just an example that I noticed.
Note: in my context I've set the default llvm to llvm12 so
that is in use.
I was interstested in what sort of problems bulk -a would have on
actual armv7 capable hardware. Otherwise emulators/mame is not
something that I use.
Side notes . . .
The GCC_LDFLAGS=3D"${LDFLAGS}" in /usr/ports/emulators/mame/Makefile
does nothing for the llvm based build that is used as far as I could
tell. Listing such a thread control option in GCC_LDFLAGS did not
result in the link command having the option (and so it still failed).
It is unfortunately that llvm has varied the notation for controlling
the linker's threading over time and that the binutils ld does not
accept a compatible notation, last I knew anyway. It may be a while
before the option text can be fixed across the then active range
of llvm* 's.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FC9D07BD-F1B3-40D6-B1AA-499284CC4A0E>