From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by sourceware.org (Postfix) with ESMTPS id 6FF0E3858434 for ; Wed, 24 Jan 2024 15:07:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6FF0E3858434 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=telecom-bretagne.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=free.fr ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6FF0E3858434 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=212.27.42.2 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706108873; cv=none; b=KSWDZ5ufpeHsUvxnsyzFdZOv4M9tKR6PyRQU9aSU6gY2DthAuVFznkkFPXuDbmHa6lkgPs8vag5zB7Du3yMEZ9oS4teMykJyVIxYAOJmdNxBlJXs9mypTi5B9fdxoaQLLwMXE6u07gISaiQz+8oELqYkcUJIRKwFsq7kEV01vfY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706108873; c=relaxed/simple; bh=DbMdzevwMGV5NgEoSbQVX81mbauXThLZe0NC+md4oJE=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=Cq3NG5cyOWyE0LxljrtJFc94syHIfsyXFVINbF59R57o+BHOt1otIxW+M4Vdf2KDFGs7DQpFseqpoaooWHEDsQDEYfpVYWIhLR9joTQ/yOB/L7NtwR3yT8dI5v5v6ww3B70XnQilGcapDEjsfUxEviNzRsB+oi1djN2kd1+iskI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from localhost (unknown [IPv6:2a01:e0a:9c:c180:c303:7a5:b16c:2c79]) (Authenticated sender: sergesanspaille@free.fr) by smtp2-g21.free.fr (Postfix) with ESMTPSA id E157B2003DA; Wed, 24 Jan 2024 16:07:48 +0100 (CET) Date: Wed, 24 Jan 2024 16:07:47 +0100 From: Serge Guelton To: Nick Clifton Cc: binutils@sourceware.org Subject: Re: RFC: Document unexpected behaviour of --fatal-warnings Message-ID: Reply-To: Serge Guelton References: <87fryomdy6.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fryomdy6.fsf@redhat.com> X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Jan 23, 2024 at 12:28:17PM +0000, Nick Clifton wrote: > Hi Guys, > > It was recently pointed out to me that the bfd linker's > --fatal-warnings option can behave in an unexpected manner. For > example: > > $ ld.bfd -z bad-option --fatal-warnings -e 0/dev/null > ld.bfd: warning: -z bad-option ignored > $ echo $? > 0 > > ie the warning about the ignored option is not being treated as an > error. This happens because the --fatal-warnings option only takes > affect after it has been processed, and we process the options in a > linear order. So the following works: > > $ ld.bfd --fatal-warnings -z bad-option -e 0 /dev/null > ld.bfd: warning: -z bad-option ignored > $ echo $? > 1 > > This behaviour differs from gold and lld, both of which honour > --fatal-warnings no matter where it occurs on the command line. > > So we could fix the linker, create a two pass argument scan and the > problem would be solved. But a) I am lazy and b) we already have a Hey Nick, In case you're worried about doing two passes, you could also record the fact that a warning has been raised in a boolean somewhere, and choke on it if --fatal-warnings was specified. Anyway, thanks for fighting the lazyness and making the effort of looking into this ;-)