[Buildroot] Analysis of build results for 2021-03-03

Giulio Benetti giulio.benetti at benettiengineering.com
Fri Mar 5 16:01:08 UTC 2021


Hi Thomas,

On 3/5/21 10:22 AM, Thomas Petazzoni wrote:
> Hello Giulio,
> 
> On Fri, 5 Mar 2021 08:56:32 +0100
> Giulio Benetti <giulio.benetti at benettiengineering.com> wrote:
> 
>> Yes, I've filed it time ago here:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847
>>
>> Then maintainer wanted me to provide all pre-preprocessed files and all
>> build flags. There the issue was showing using Codesourcery only, but
>> here we have a Buildroot toolchain, so better chance to dig.
> 
> Indeed!

Need to provide more details on gcc bug then.

>> Anyway I can add patches to add the _BUG_ and use the -O0 workaround.
>> What about that?
> 
> Sure, sounds good.
> 
>>>>      nios2     |        belle-sip-4.4.8         | NOK | http://autobuild.buildroot.net/results/71f26fd81db8e9b19b3f18f3f3cefd9c768f094f |
>>>
>>> /tmp/ccDtjRfo.s: Assembler messages:
>>> /tmp/ccDtjRfo.s:210798: Error: branch offset out of range
>>>
>>> Another wonderful nios2 toolchain issue. Giulio, what do you think ?
>>
>> This is new to me, I've checked on Gcc Bugzilla and it doesn't seem to
>> be there. So I can file it up and look for a workaround, maybe the usual
>> -O0.
> 
> With these errors, I'm never sure if it's a gcc issue (that emits bogus
> assembly) or a binutils issue. But most likely a gcc issue.

It's a gcc bug and worked around with this patchset:
https://patchwork.ozlabs.org/project/buildroot/list/?series=232394

> 
>>>>      nios2     |         libgeos-3.9.0          | NOK | http://autobuild.buildroot.net/results/a05fdf1958f93a206c5c66c7f636b6650683626d | ORPH
>>>
>>> Some more nios2 toolchain issue.
>>
>> This is very similar to one of Microblaze gcc bugs. So I could be able
>> to workaround it with the same -O0.

For this I don't find any work-around. I've found this patch from Nios 
gcc mantainer:
https://patchwork.ozlabs.org/project/gcc/patch/b652a8a6-dcad-bbe6-4ec8-bc0cb3d71d45@codesourcery.com/

where she states that it could have fixed the bug due too many linker 
warnings, but at the end she reverted. So no way.
Since I've tried building libgeos with gcc7/8/9/10 unsuccesfully,
for this package then I've sent this patch to disable it while building 
for Nios:
https://patchwork.ozlabs.org/project/buildroot/patch/20210305160005.3826615-1-giulio.benetti@benettiengineering.com/

> OK.
> 
> Maybe we should default to -O2 for those funky architectures? Indeed,
> our default is -Os, but this is perhaps less widely used/tested than
> -O2 ?
> 
> Or are the bugs in question also appearing at -O2 ?

Unfortunately they show also with -O2, so we should entirely build with 
-O0 but that would results in a very big rootfs. So for the moment IMHO 
I would keep sending these workarounds.

>>> Should we get rid of nios2 support entirely ?
>>
>> Here it seems we get to the same point of Microblaze, if there is no
>> hurry I can provide patches to save Nios the same way I've done for
>> Microblaze.
> 
> My concern is that those gcc issues for nios2/microblaze never seem to
> be fixed. That there are gcc issues that we need to workaround, it's
> fine I guess, but that they stay forever is more annoying.

Judging from the last 2 years, yes they won't be fixed at 90%...

> 
>>>>       arm      | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/d9b9a4b7c3660bd730a19ab09e44f24bc29e3f40 | ORPH
>>>>       arm      | toolchain-external-linaro-a... | NOK | http://autobuild.buildroot.net/results/13f9a551f5ac911e7daa2a382b0683d81486cffa | ORPH
>>>
>>> toolchain is gone ?
>>
>> Here it's Micronova firewall that blocks it, I've just written to my IT.
> 
> OK, thanks!
> 
>>>>     powerpc    |            unknown             | NOK | http://autobuild.buildroot.net/results/159d2c07060c235080711d1d0da0b2eae995d4bf |
>>>
>>> This is a top-level parallel build issue... but since we don't have the
>>> full log, we don't have the error.
>>>
>>> Should we perhaps keep the full log, compressed, for builds done in
>>> parallel ?
>>
>> I see it's on my Autobuilder, what can I do to provide suck full log? Do
>> you mean the entire Buildroot log? If yes I can try to reproduce it and
>> save it on a file and post it in some way.
> 
> Now that the build is finished, the build log is gone. My proposal here
> was to adjust the autobuild-run script to upload to
> autobuild.buildroot.org the full build log (compressed) when the build
> is a top-level parallel build.

Ah ok!

>>>>       or1k     |          zeromq-4.3.4          | NOK | http://autobuild.buildroot.net/results/ed105d321c0bde99c293ab7328d57c3764db6f27 |
>>>>       or1k     |          zeromq-4.3.4          | NOK | http://autobuild.buildroot.net/results/ce351e0e97c2cacc17d4718d39941548c7558559 |
>>>
>>> /home/giuliobenetti/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.33.1 assertion fail elf32-or1k.c:2329
>>> collect2: error: ld returned 1 exit status
>>>
>>> Giulio, is this a known or1k issue ?
>>
>> Yes, for this I've sent a patchset time ago:
>> https://patchwork.ozlabs.org/project/buildroot/list/?series=161548
>>
>> So basically zeromq should be disabled like protobuf. But need to check it.
>>
>> You've also answered me here:
>> https://patchwork.ozlabs.org/project/buildroot/patch/20200228175814.128730-1-giulio.benetti@benettiengineering.com/
>>
>> Here it seems the same situation as Nios and Microblaze.
>>
>> For this I can provide patches too if not in hurry.
> 
> Maybe we should be pragmatic here and just take your patches as-is.

They still apply to master branch too.

I've also sent these patches since 2 Microblaze bugs have been fixed in 
gcc 10.x:
https://patchwork.ozlabs.org/project/buildroot/patch/20210305153730.3671327-1-giulio.benetti@benettiengineering.com/
https://patchwork.ozlabs.org/project/buildroot/patch/20210305154139.3682817-1-giulio.benetti@benettiengineering.com/

Best regards
-- 
Giulio Benetti
Benetti Engineering sas


More information about the buildroot mailing list