public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* ☠ Buildbot (Sourceware): binutils-gdb - failed test (failure) test (failure) (master)
@ 2024-04-16 15:22 builder
  2024-04-16 15:36 ` Mark Wielaard
  0 siblings, 1 reply; 6+ messages in thread
From: builder @ 2024-04-16 15:22 UTC (permalink / raw)
  To: binutils

A new failure has been detected on builder binutils-ubuntu-riscv while building binutils-gdb.

Full details are available at:
    https://builder.sourceware.org/buildbot/#/builders/283/builds/367

Build state: failed test (failure) test (failure)
Revision: 3f6a060c7543332d0cb4377fc318e2db01ea1d3c
Worker: starfive-2
Build Reason: (unknown)
Blamelist: A. Wilcox <awilfox@adelielinux.org>, Aaron Merey <amerey@redhat.com>, Abdul Basit Ijaz <abdul.b.ijaz@intel.com>, Aditya Kamath <Aditya.Kamath1@ibm.com>, Aditya Vidyadhar Kamath <ADITYA.VIDYADHAR.KAMATH@ibm.com>, Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>, Alan Modra <amodra@gmail.com>, Aleksandar Paunovic <aleksandar.paunovic@intel.com>, Alex Coplan <alex.coplan@arm.com>, Alexandra Hájková <ahajkova@redhat.com>, Alexandre Oliva <oliva@adacore.com>, Alexey Lapshin <alexey.lapshin@espressif.com>, Alok Kumar Sharma <AlokKumar.Sharma@amd.com>, Andre Vieira <andre.simoesdiasvieira@arm.com>, Andrea Corallo <andrea.corallo@arm.com>, Andreas Arnez <arnez@linux.ibm.com>, Andreas K. Huettel <dilfridge@gentoo.org>, Andreas Krebbel <krebbel@linux.ibm.com>, Andreas Schwab <schwab@linux-m68k.org>, Andreas Schwab <schwab@suse.de>, Andrew Burgess <aburgess@redhat.com>, Andrew Burgess <andrew.burgess@embecosm.com>, Andrew Carlotti <andrew.carlotti@arm.com>, Andrew Pinski <apinski@marvell.com>, Ari Hannula <ari.hannula@intel.com>, Arsen Arsenovi? <arsen@aarsen.me>, Arsen Arsenović <arsen@aarsen.me>, Benson Muite <benson_muite@emailplus.org>, Bernd Edlinger <bernd.edlinger@hotmail.de>, Bernhard Heckel <bernhard.heckel@intel.com>, Bernhard M. Wiedemann <bwiedemann@suse.de>, Bhuvanendra Kumar N <Bhuvanendra.KumarN@amd.com>, Branislav Brzak <branislav.brzak@syrmia.com>, Brett Werling <bwerl.dev@gmail.com>, Bruno Larsen <blarsen@redhat.com>, CaiJingtao <caijingtao@huawei.com>, Carl Love <cel@linux.ibm.com>, Carl Love <cel@us.ibm.com>, Cary Coutant <ccoutant@gmail.com>, Christina Schimpe <christina.schimpe@intel.com>, Christoph Müllner <christoph.muellner@vrull.eu>, Christophe Lyon <christophe.lyon@arm.com>, Christophe Lyon <christophe.lyon@linaro.org>, Christophe Lyon <christophe.lyon@st.com>, Christopher Di Bella <cjdb@google.com>, Chung-Ju Wu <jasonwucj@gmail.com>, Ciaran Woodward <ciaranwoodward@xmos.com>, Claudio Bantaloukas <Claudio.Bantaloukas@arm.com>, Claudiu Zissulescu <claziss@gmail.com>, Claudiu Zissulescu <claziss@synopsys.com>, Clément Chigot <chigot@adacore.com>, Cristian Sandu <cristian.sandu@intel.com>, Cui, Lili <lili.cui@intel.com>, Cui,Lili <lili.cui@intel.com>, Cupertino Miranda <cupertino.miranda@oracle.com>, Dan Callaghan <dan.callaghan@morsemicro.com>, David Carew <david@dcarew.com>, David Faust <david.faust@oracle.com>, David Guillen Fandos <david@davidgf.net>, David Seifert <soap@gentoo.org>, Dimitar Dimitrov <dimitar@dinux.eu>, Dmitry Selyutin <ghostmansd@gmail.com>, Eli Zaretskii <eliz@gnu.org>, Enze Li <enze.li@gmx.com>, Enze Li <enze.li@hotmail.com>, Eugene Rozenfeld <erozen@microsoft.com>, Ezra Sitorus <ezra.sitorus@arm.com>, Fangrui Song <i@maskray.me>, Fangrui Song <maskray@google.com>, Feiyang Chen <chenfeiyang@loongson.cn>, Felix Willgerodt <felix.willgerodt@intel.com>, Flavio Cruz <flaviocruz@gmail.com>, Frederic Cambus <fred@statdns.com>, GDB Administrator <gdbadmin@sourceware.org>, Gaius Mulley <gaiusmod2@gmail.com>, Gareth Rees <grees@undo.io>, Georg-Johann Lay <avr@gjlay.de>, Gregory Anders <greg@gpanders.com>, Guillermo E. Martinez <guillermo.e.martinez@oracle.com>, Guinevere Larsen <blarsen@redhat.com>, H.J. Lu <hjl.tools@gmail.com>, Hannes Domani <ssbssa@yahoo.de>, Hans-Peter Nilsson <hp@axis.com>, Haochen Jiang <haochen.jiang@intel.com>, Hau Hsu <hau.hsu@sifive.com>, Himal <himalr@proton.me>, Hongyu Wang <hongyu.wang@intel.com>, Hsinyuan Xavier <TheLastLin@hotmail.com>, Hu, Lin1 <lin1.hu@intel.com>, Hui Li <lihui@loongson.cn>, Iain Buclaw <ibuclaw@gcc.gnu.org>, Iain Buclaw <ibuclaw@gdcproject.org>, Iain Sandoe <iain@sandoe.co.uk>, Ijaz, Abdul B <abdul.b.ijaz@intel.com>, Ilya Leoshkevich <iii@linux.ibm.com>, Indu Bhagat <indu.bhagat@oracle.com>, Jacob Navia <jacob@jacob.remcomp.fr>, Jakub Jelinek <jakub@redhat.com>, Jan Beulich <jbeulich@suse.com>, Jan Kratochvil <jan.kratochvil@redhat.com>, Jan Vrany <jan.vrany@labware.com>, Jan-Benedict Glaw <jbglaw@lug-owl.de>, Jason Merrill <jason@redhat.com>, Jaydeep Patil <Jaydeep.Patil@imgtec.com>, Jaydeep Patil <jaydeep.patil@imgtec.com>, Jedidiah Thompson <wej22007@outlook.com>, Jeff Law <jeffreyalaw@gmail.com>, Jeff Law <jlaw@ventanamicro.com>, Jens Remus <jremus@linux.ibm.com>, Jerry Zhang Jian <jerry.zhangjian@sifive.com>, Jia-Wei Chen <jiawei@iscas.ac.cn>, Jiajie Chen <c@jia.je>, Jiangshuai Li <jiangshuai_li@c-sky.com>, Jiangshuai Li <jiangshuai_li@linux.alibaba-inc.com>, Jiangshuai Li <jiangshuai_li@linux.alibaba.com>, Jiawei <jiawei@iscas.ac.cn>, Jim Wilson <jimw@sifive.com>, Jin Ma <jinma@linux.alibaba.com>, Jinyang He <hejinyang@loongson.cn>, Joel Brobecker <brobecker@adacore.com>, Johannes Schauer Marin Rodrigues <josch@debian.org>, John Baldwin <jhb@FreeBSD.org>, John David Anglin <danglin@gcc.gnu.org>, Johnson Sun <j3.soon777@gmail.com>, Jojo R <rjiejie@linux.alibaba.com>, Jon Turney <jon.turney@dronecode.org.uk>, Jonas Hoerberg <JHorberg@danfoss.com>, Jonathan Wakely <jwakely@redhat.com>, Jose E. Marchesi <jose.marchesi@oracle.com>, Joseph Faulls <Joseph.Faulls@imgtec.com>, Joseph Myers <joseph@codesourcery.com>, Joseph Myers <josmyers@redhat.com>, Joseph Myers <jsm@polyomino.org.uk>, Jozef Lawrynowicz <jozefl@gcc.gnu.org>, Kalvis Duckmanton <kalvisd@gmail.com>, Kavitha Natarajan <kavitha.natarajan@amd.com>, Kaylee Blake <klkblake@gmail.com>, Keith Seitz <keiths@redhat.com>, Kevin Buettner <kevinb@redhat.com>, Khem Raj <raj.khem@gmail.com>, Kito Cheng <kito.cheng@sifive.com>, Kong Lingling <lingling.kong@intel.com>, Konstantin Isakov <ikm@zbackup.org>, Kuan-Lin Chen <rufus@andestech.com>, Kumar N, Bhuvanendra <Kavitha.Natarajan@amd.com>, Kévin Le Gouguec <legouguec@adacore.com>, LIU Hao <lh_mouse@126.com>, Lancelot SIX <lancelot.six@amd.com>, Lancelot Six <lancelot.six@amd.com>, Laurent Morichetti <laurent.morichetti@amd.com>, Li Xu <xuli1@eswincomputing.com>, Lifang Xia <lifang_xia@linux.alibaba.com>, Luca Bacci <luca.bacci@outlook.com>, Luca Boccassi <bluca@debian.org>, Luca Bonissi <gcc@scarsita.it>, Ludovic Courtès <ludo@gnu.org>, Luis Machado <luis.machado@arm.com>, Lulu Cai <cailulu@loongson.cn>, Lulu Cheng <chenglulu@loongson.cn>, Maciej W. Rozycki <macro@embecosm.com>, Maciej W. Rozycki <macro@orcam.me.uk>, Magne Hov <mhov@undo.io>, Manoj Gupta <manojgupta@google.com>, Marcus Nilsson <brainbomb@gmail.com>, Marek Polacek <polacek@redhat.com>, Mark Harmstone <mark@harmstone.com>, Mark Wielaard <mark@klomp.org>, Markus Metzger <markus.t.metzger@intel.com>, Martin Liska <mliska@suse.cz>, Martin Storsjö <martin@martin.st>, Mary Bennett <mary.bennett@embecosm.com>, Matheus Branco Borella <dark.ryu.550@gmail.com>, Matthew "strager" Glazar <strager.nds@gmail.com>, Matthew Malcomson <hardenedapple@gmail.com>, Matthias Klose <doko@debian.org>, Matthieu Longo <matthieu.longo@arm.com>, Matti Puputti <matti.puputti@intel.com>, Max Filippov <jcmvbkbc@gmail.com>, Meghan Denny <hello@nektro.net>, Michael J. Eager <eager@eagercon.com>, Michael Matz <matz@suse.de>, Mihails Strasuns <mihails.strasuns@intel.com>, Mike Frysinger <vapier@gentoo.org>, Mo, Zewei <zewei.mo@intel.com>, Mohamed Bouhaouel <mohamed.bouhaouel@intel.com>, Nandakumar Edamana <nandakumar@nandakumar.co.in>, Natarajan, Kavitha <Kavitha.Natarajan@amd.com>, Nathan Huckleberry <nhuck@google.com>, Nathan Sidwell <nathan@acm.org>, Neal Frager <neal.frager@amd.com>, Neal frager <neal.frager@amd.com>, Nelson Chu <nelson.chu@sifive.com>, Nelson Chu <nelson@nelson.ba.rivosinc.com>, Nelson Chu <nelson@rivosinc.com>, Nick Alcock <nick.alcock@oracle.com>, Nick Clifton <nickc@redhat.com>, Nicolas Boulenguez <nicolas.boulenguez@free.fr>, Nicolas Boulenguez <nicolas@debian.org>, Nikolaos Chatzikonstantinou <nchatz314@gmail.com>, Nils-Christian Kempke <nils-christian.kempke@intel.com>, Oleg Tolmatcev <oleg.tolmatcev@gmail.com>, Olivier Hainque <hainque@adacore.com>, Orgad Shaneh <orgads@gmail.com>, Palmer Dabbelt <palmer@rivosinc.com>, Patrick Monnerat <patrick@monnerat.net>, Patrick O'Neill <patrick@rivosinc.com>, Paul Iannetta <piannetta@kalrayinc.com>, Paul Koning <paulkoning@comcast.net>, Paul Pluzhnikov <ppluzhnikov@google.com>, Pedro Alves <palves@redhat.com>, Pedro Alves <pedro@palves.net>, Pekka Seppänen <pexu@sourceware.mail.kapsi.fi>, Peter Bergner <bergner@linux.ibm.com>, Peter Edwards <peadar@arista.com>, Peter Foley <pefoley2@pefoley.com>, Peter Jones <pjones@redhat.com>, Petr Tesarik <petr@tesarici.cz>, Philip Herron <philip.herron@embecosm.com>, Philipp Tomsich <philipp.tomsich@vrull.eu>, Philippe Blain <levraiphilippeblain@gmail.com>, Philippe Waroquiers <philippe.waroquiers@skynet.be>, Potharla, Rupesh <Rupesh.Potharla@amd.com>, Pter Chubb <peter.chubb@unsw.edu.au>, Puputti, Matti <matti.puputti@intel.com>, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>, Ralf Habacker <ralf.habacker@freenet.de>, Richard Ball <richard.ball@arm.com>, Richard Bunt <richard.bunt@linaro.org>, Richard Earnshaw <rearnsha@arm.com>, Richard Purdie <richard.purdie@linuxfoundation.org>, Richard Sandiford <richard.sandiford@arm.com>, Richard W.M. Jones <rjones@redhat.com>, Roger Sayle <roger@nextmovesoftware.com>, Rohr, Stephan <stephan.rohr@intel.com>, Roland McGrath <mcgrathr@google.com>, Romain Geissler <romain.geissler@amadeus.com>, Rui Ueyama <rui314@gmail.com>, Rupesh Potharla <Rupesh.Potharla@amd.com>, Ruud van der Pas <ruud.vanderpas@oracle.com>, Sam James <sam@gentoo.org>, Samuel Tardieu <sam@rfc1149.net>, Sandra Loosemore <sandra@codesourcery.com>, Sandra Loosemore <sloosemore@baylibre.com>, Saurabh Jha <saurabh.jha@arm.com>, Schimpe, Christina <christina.schimpe@intel.com>, Sergei Trofimovich <siarheit@google.com>, Sergey Bugaev <bugaevc@gmail.com>, Shahab Vahedi <shahab@synopsys.com>, Shihua <shihua@iscas.ac.cn>, Simon Cook <simon.cook@embecosm.com>, Simon Farre <simon.farre.cx@gmail.com>, Simon Marchi <simon.marchi@efficios.com>, Simon Marchi <simon.marchi@polymtl.ca>, Song Mengzhi <song.mengzhi@zte.com.cn>, Srinath Parvathaneni <srinath.parvathaneni@arm.com>, Stafford Horne <shorne@gmail.com>, Stam Markianos-Wright <stam.markianos-wright@arm.com>, Stefan Liebler <stli@linux.ibm.com>, Stefan Schulze Frielinghaus <stefansf@linux.ibm.com>, Stefano Moioli <smxdev4@gmail.com>, Steinar H. Gunderson <sesse@google.com>, Steinar H. Gunderson <steinar+sourceware@gunderson.no>, Stepan Nemec <stepnem@gmail.com>, Stephen Kitt <steve@sk2.org>, Szabolcs Nagy <szabolcs.nagy@arm.com>, TaiseiIto <taisei1212@outlook.jp>, Tamar Christina <tamar.christina@arm.com>, Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>, Tatsuyuki Ishi <ishitatsuyuki@gmail.com>, Tejas Joshi <TejasSanjay.Joshi@amd.com>, Thiago Jung Bauermann <thiago.bauermann@linaro.org>, Thomas Hebb <tommyhebb@gmail.com>, Thomas Koenig <tkoenig@netcologne.de>, Thomas Schwinge <thomas@codesourcery.com>, Thomas Weißschuh <thomas@t-8ch.de>, Tiezhu Yang <yangtiezhu@loongson.cn>, Tobias Burnus <tobias@codesourcery.com>, Toby Lloyd Davies <tlloyddavies@undo.io>, Tom Tromey <tom@tromey.com>, Tom Tromey <tromey@adacore.com>, Tom de Vries <tdevries@jostaberry-8.arch.suse.de>, Tom de Vries <tdevries@loganberry-1.arch.suse.de>, Tom de Vries <tdevries@space.suse.cz>, Tom de Vries <tdevries@suse.de>, Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>, Tomoaki Kawada <kawada@kmckk.co.jp>, Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>, Tristan Gingold <tgingold@free.fr>, Tsukasa OI <research_trasio@irq.a4lg.com>, Ulf Samuelsson <ulf@emagii.com>, Victor Do Nascimento <Victor.DoNascimento@arm.com>, Victor Do Nascimento <victor.donascimento@arm.com>, Vijay Shankar <shank.vijay@yandex.com>, Vladimir Mezentsev <vladimir.mezentsev@oracle.com>, Vladislav Belov <vladislav.belov@syntacore.com>, Vladislav Khmelevsky <och95@yandex.ru>, Vsevolod Alekseyev <sevaa@sprynet.com>, WANG Rui <r@hev.cc>, WANG Xuerui <git@xen0n.name>, Weimin Pan <weimin.pan@oracle.com>, Will Hawkins <hawkinsw@obs.cr>, Willgerodt, Felix <felix.willgerodt@intel.com>, Xi Ruoyao <xry111@mengyan1223.wang>, Xi Ruoyao <xry111@xry111.site>, Xianmiao Qu <cooper.qu@linux.alibaba.com>, Xiao Zeng <zengxiao@eswincomputing.com>, Yang Liu <liuyang22@iscas.ac.cn>, Yichao Yu <yyc1992@gmail.com>, Ying Huang <ying.huang@oss.cipunited.com>, Yoshinori Sato <ysato@users.sourceforge.jp>, Youling Tang <tangyouling@loongson.cn>, YunQiang Su <yunqiang.su@cipunited.com>, Yuriy Kolerov <Yuriy.Kolerov@synopsys.com>, Yuriy Kolerov <kolerov93@gmail.com>, Yury Khrustalev <Yury.Khrustalev@arm.com>, Yury Khrustalev <yury.khrustalev@arm.com>, Yvan Roux <yvan.roux@foss.st.com>, Zac Walker <zac.walker@linaro.org>, Zac Walker <zacwalker@microsoft.com>, Zeke Lu <lvzecai@gmail.com>, Zhang, Jun <jun.zhang@intel.com>, Zhiqing Xiong <zhiqxion@qti.qualcomm.com>, cailulu <cailulu@loongson.cn>, caiyinyu <caiyinyu@loongson.cn>, changjiachen <changjiachen@stu.xupt.edu.cn>, jiawei <jiawei@iscas.ac.cn>, konglin1 <lingling.kong@intel.com>, liuhongt <hongtao.liu@intel.com>, liuzhensong <liuzhensong@loongson.cn>, mengqinggang <mengqinggang@loongson.cn>, mga-sc <mark.goncharov@syntacore.com>, rupesh potharla <rupesh.potharla@amd.com>, rupothar <rupesh.potharla@amd.com>, srinath <srinath.parvathaneni@arm.com>, tangxiaolin <tangxiaolin@loongson.cn>, ticat_fp <fanpeng@loongson.cn>, yaowenbin <yaowenbin1@huawei.com>, zengxiao <zengxiao@eswincomputing.com>, Дилян Палаузов <dilyan.palauzov@aegee.org>, Сергей Чернов <klen_s@mail.ru>

Steps:

- 0: worker_preparation ( success )

- 1: git checkout ( success )
    Logs:
        - stdio: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/1/logs/stdio

- 2: rm -rf binutils-build ( success )
    Logs:
        - stdio: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/2/logs/stdio

- 3: configure ( success )
    Logs:
        - stdio: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/3/logs/stdio
        - config.log: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/3/logs/config_log

- 4: make ( warnings )
    Logs:
        - stdio: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/4/logs/stdio
        - warnings (12): https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/4/logs/warnings__12_

- 5: make check gas binutils ( failure )
    Logs:
        - stdio: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/5/logs/stdio
        - gas.sum: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/5/logs/gas_sum
        - gas.log: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/5/logs/gas_log
        - binutils.sum: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/5/logs/binutils_sum
        - binutils.log: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/5/logs/binutils_log
        - warnings (4): https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/5/logs/warnings__4_

- 6: make check ld ( failure )
    Logs:
        - stdio: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/6/logs/stdio
        - ld.sum: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/6/logs/ld_sum
        - ld.log: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/6/logs/ld_log
        - warnings (2): https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/6/logs/warnings__2_

- 7: prep ( success )
    Logs:
        - stdio: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/7/logs/stdio

- 8: build bunsen.cpio.gz ( success )
    Logs:
        - stdio: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/8/logs/stdio

- 9: fetch bunsen.cpio.gz ( success )
    Logs:
        - stdio: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/9/logs/stdio

- 10: unpack bunsen.cpio.gz ( success )
    Logs:
        - stdio: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/10/logs/stdio

- 11: pass .bunsen.source.gitname ( success )
    Logs:
        - stdio: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/11/logs/stdio

- 12: pass .bunsen.source.gitdescribe ( success )
    Logs:
        - stdio: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/12/logs/stdio

- 13: pass .bunsen.source.gitbranch ( success )
    Logs:
        - stdio: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/13/logs/stdio

- 14: pass .bunsen.source.gitrepo ( success )
    Logs:
        - stdio: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/14/logs/stdio

- 15: upload to bunsen ( success )
    Logs:
        - stdio: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/15/logs/stdio

- 16: clean up ( success )
    Logs:
        - stdio: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/16/logs/stdio

- 17: rm -rf binutils-build_1 ( success )
    Logs:
        - stdio: https://builder.sourceware.org/buildbot/#/builders/283/builds/367/steps/17/logs/stdio


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ☠ Buildbot (Sourceware): binutils-gdb - failed test (failure) test (failure) (master)
  2024-04-16 15:22 ☠ Buildbot (Sourceware): binutils-gdb - failed test (failure) test (failure) (master) builder
@ 2024-04-16 15:36 ` Mark Wielaard
  2024-04-16 15:45   ` Nick Clifton
  0 siblings, 1 reply; 6+ messages in thread
From: Mark Wielaard @ 2024-04-16 15:36 UTC (permalink / raw)
  To: binutils; +Cc: nickc

Hi,

On Tue, 2024-04-16 at 15:22 +0000, builder@sourceware.org wrote:
> A new failure has been detected on builder binutils-ubuntu-riscv while building binutils-gdb.
> 
> Full details are available at:
>     https://builder.sourceware.org/buildbot/#/builders/283/builds/367
> 
> Build state: failed test (failure) test (failure)
> Revision: 3f6a060c7543332d0cb4377fc318e2db01ea1d3c
> Worker: starfive-2
> Build Reason: (unknown)
> Blamelist: [... way too many people ...]

Groan, sorry, it seems to be a real regression on riscv (in binutils).
But because ld did see failures before buildbot seems to get confused
who to "blame"...

This issue flagged is:

Executing on host: /var/lib/buildbot/workers/sourceware/binutils-
ubuntu-riscv/binutils-build/binutils/objcopy  --preserve-dates
tmpdir/bintest tmpdir/copy   (timeout = 300)
spawn -ignore SIGHUP /var/lib/buildbot/workers/sourceware/binutils-
ubuntu-riscv/binutils-build/binutils/objcopy --preserve-dates
tmpdir/bintest tmpdir/copy
cmp tmpdir/bintest tmpdir/copy
Executing on build: cmp tmpdir/bintest tmpdir/copy   (timeout = 300)
spawn -ignore SIGHUP cmp tmpdir/bintest tmpdir/copy
tmpdir/bintest tmpdir/copy differ: char 73, line 1
tmpdir/bintest tmpdir/copy differ: char 73, line 1
FAIL: objcopy executable (pr25662)

Caused by:

commit 3f6a060c7543332d0cb4377fc318e2db01ea1d3c (HEAD -> master,
origin/master, origin/HEAD)
Author: Nick Clifton <nickc@redhat.com>
Date:   Tue Apr 16 15:06:05 2024 +0100

    Remove accidental commit of an experimental change

diff --git a/binutils/testsuite/binutils-all/pr25662.ld
b/binutils/testsuite/binutils-all/pr25662.ld
index 4951184f88ef..19ef1391f8d9 100644
--- a/binutils/testsuite/binutils-all/pr25662.ld
+++ b/binutils/testsuite/binutils-all/pr25662.ld
@@ -12,6 +12,4 @@ SECTIONS
   .text : { *(.text) } > ROM
 
   .bss : { *(.bss) } > RAM
-
-  /DISCARD/ : { *(.*) }
 }

So maybe this testcase accidentially succeeded on riscv, but was
supposed to fail?

Cheers,

Mark

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ☠ Buildbot (Sourceware): binutils-gdb - failed test (failure) test (failure) (master)
  2024-04-16 15:36 ` Mark Wielaard
@ 2024-04-16 15:45   ` Nick Clifton
  2024-04-16 15:54     ` Palmer Dabbelt
  0 siblings, 1 reply; 6+ messages in thread
From: Nick Clifton @ 2024-04-16 15:45 UTC (permalink / raw)
  To: Mark Wielaard, binutils

Hi Mark,

> Groan, sorry, it seems to be a real regression on riscv (in binutils).
> But because ld did see failures before buildbot seems to get confused
> who to "blame"...

> Caused by:
>      Remove accidental commit of an experimental change


> diff --git a/binutils/testsuite/binutils-all/pr25662.ld
> b/binutils/testsuite/binutils-all/pr25662.ld
> index 4951184f88ef..19ef1391f8d9 100644
> --- a/binutils/testsuite/binutils-all/pr25662.ld
> +++ b/binutils/testsuite/binutils-all/pr25662.ld
> @@ -12,6 +12,4 @@ SECTIONS
>     .text : { *(.text) } > ROM
>   
>     .bss : { *(.bss) } > RAM
> -
> -  /DISCARD/ : { *(.*) }
>   }
> 
> So maybe this testcase accidentially succeeded on riscv, but was
> supposed to fail?

Doh - now I remember what I was trying to fix.  The Risc-V targets
are creating a RISCV_ATTRIBUTES section which gets moved to a new
address when the binary is objcopy'ed.  I was wondering if special
sections like this were expected to survive the copy completely
unchanged, and decided to try dropping them the link entirely.  But
I failed to follow up on why the RISCV_ATTRIBUTES section moves
and - as Alan pointed out - dropping special sections creates new
problems for other targets.

So I need to go back to the Risc-V code in the BFD backend and see
if I can find out why this section is causing problems for objcopy.

Cheers
   Nick


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ☠ Buildbot (Sourceware): binutils-gdb - failed test (failure) test (failure) (master)
  2024-04-16 15:45   ` Nick Clifton
@ 2024-04-16 15:54     ` Palmer Dabbelt
  2024-04-16 16:23       ` Nick Clifton
  0 siblings, 1 reply; 6+ messages in thread
From: Palmer Dabbelt @ 2024-04-16 15:54 UTC (permalink / raw)
  To: Nick Clifton; +Cc: mark, binutils

On Tue, 16 Apr 2024 08:45:00 PDT (-0700), Nick Clifton wrote:
> Hi Mark,
>
>> Groan, sorry, it seems to be a real regression on riscv (in binutils).
>> But because ld did see failures before buildbot seems to get confused
>> who to "blame"...
>
>> Caused by:
>>      Remove accidental commit of an experimental change
>
>
>> diff --git a/binutils/testsuite/binutils-all/pr25662.ld
>> b/binutils/testsuite/binutils-all/pr25662.ld
>> index 4951184f88ef..19ef1391f8d9 100644
>> --- a/binutils/testsuite/binutils-all/pr25662.ld
>> +++ b/binutils/testsuite/binutils-all/pr25662.ld
>> @@ -12,6 +12,4 @@ SECTIONS
>>     .text : { *(.text) } > ROM
>>
>>     .bss : { *(.bss) } > RAM
>> -
>> -  /DISCARD/ : { *(.*) }
>>   }
>>
>> So maybe this testcase accidentially succeeded on riscv, but was
>> supposed to fail?
>
> Doh - now I remember what I was trying to fix.  The Risc-V targets
> are creating a RISCV_ATTRIBUTES section which gets moved to a new
> address when the binary is objcopy'ed.  I was wondering if special
> sections like this were expected to survive the copy completely
> unchanged, and decided to try dropping them the link entirely.  But
> I failed to follow up on why the RISCV_ATTRIBUTES section moves
> and - as Alan pointed out - dropping special sections creates new
> problems for other targets.
>
> So I need to go back to the Risc-V code in the BFD backend and see
> if I can find out why this section is causing problems for objcopy.

I can't think of any reason the RISC-V attributes would specifically 
trip up on an objcopy that doesn't change anything else.  We've got some 
string-based attributes, but if nothing else changes they should stay 
the same too.  There's also some attribute merging code, but again that 
shouldn't change anything.

That said, I wouldn't be surprised if we have some bug floating around 
there somewhere.  The attributes aren't all that widely used (they sort 
of just store a bunch of stuff that doesn't have much meaning, we've 
gotten burned by backwards compatability there a few times).  I think 
tooling mostly ignores them these days.

LMK if you want Nelson or I to look, but happpy to have the help ;)

>
> Cheers
>    Nick

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ☠ Buildbot (Sourceware): binutils-gdb - failed test (failure) test (failure) (master)
  2024-04-16 15:54     ` Palmer Dabbelt
@ 2024-04-16 16:23       ` Nick Clifton
  2024-04-16 17:36         ` Palmer Dabbelt
  0 siblings, 1 reply; 6+ messages in thread
From: Nick Clifton @ 2024-04-16 16:23 UTC (permalink / raw)
  To: Palmer Dabbelt; +Cc: mark, binutils

Hi Palmer,

> I can't think of any reason the RISC-V attributes would specifically trip up on an objcopy that doesn't change anything else.  We've got some string-based attributes, but 
> if nothing else changes they should stay the same too.  There's also some attribute merging code, but again that shouldn't change anything.
> 
> That said, I wouldn't be surprised if we have some bug floating around there somewhere.  The attributes aren't all that widely used (they sort of just store a bunch of 
> stuff that doesn't have much meaning, we've gotten burned by backwards compatability there a few times).  I think tooling mostly ignores them these days.
> 
> LMK if you want Nelson or I to look, but happpy to have the help ;)

Thanks for the offer, but I think that I have already found the problem.
The issue was that the .riscv_attributes section was appearing before
the .text section in BFD's list of sections to allocate to segments.
This was then tripping up on a bug in the fix for PR 31450 which made
the BFD library think that it needed to rework the section to segment
mapping which then meant that the RISCV_ATTRIBUTES segment was moved to
a different address which finally resulted in objcopy producing a changed
binary.  (phew!)

Anyway I am testing a patch locally which I think will fix the problem.

Cheers
   Nick




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ☠ Buildbot (Sourceware): binutils-gdb - failed test (failure) test (failure) (master)
  2024-04-16 16:23       ` Nick Clifton
@ 2024-04-16 17:36         ` Palmer Dabbelt
  0 siblings, 0 replies; 6+ messages in thread
From: Palmer Dabbelt @ 2024-04-16 17:36 UTC (permalink / raw)
  To: Nick Clifton; +Cc: mark, binutils

On Tue, 16 Apr 2024 09:23:20 PDT (-0700), Nick Clifton wrote:
> Hi Palmer,
>
>> I can't think of any reason the RISC-V attributes would specifically trip up on an objcopy that doesn't change anything else.  We've got some string-based attributes, but
>> if nothing else changes they should stay the same too.  There's also some attribute merging code, but again that shouldn't change anything.
>>
>> That said, I wouldn't be surprised if we have some bug floating around there somewhere.  The attributes aren't all that widely used (they sort of just store a bunch of
>> stuff that doesn't have much meaning, we've gotten burned by backwards compatability there a few times).  I think tooling mostly ignores them these days.
>>
>> LMK if you want Nelson or I to look, but happpy to have the help ;)
>
> Thanks for the offer, but I think that I have already found the problem.
> The issue was that the .riscv_attributes section was appearing before
> the .text section in BFD's list of sections to allocate to segments.
> This was then tripping up on a bug in the fix for PR 31450 which made
> the BFD library think that it needed to rework the section to segment
> mapping which then meant that the RISCV_ATTRIBUTES segment was moved to
> a different address which finally resulted in objcopy producing a changed
> binary.  (phew!)
>
> Anyway I am testing a patch locally which I think will fix the problem.

Awesome, thanks!

>
> Cheers
>    Nick

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2024-04-16 17:36 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-16 15:22 ☠ Buildbot (Sourceware): binutils-gdb - failed test (failure) test (failure) (master) builder
2024-04-16 15:36 ` Mark Wielaard
2024-04-16 15:45   ` Nick Clifton
2024-04-16 15:54     ` Palmer Dabbelt
2024-04-16 16:23       ` Nick Clifton
2024-04-16 17:36         ` Palmer Dabbelt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).