From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=v/5O=JC=gentoo.org=sam@sourceware.org>
Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4])
	by sourceware.org (Postfix) with ESMTP id D41FD3858D37
	for <binutils@sourceware.org>; Wed, 24 Jan 2024 15:14:39 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D41FD3858D37
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D41FD3858D37
Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:ea4a:1:5054:ff:fec7:86e4
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706109281; cv=none;
	b=nuz4C0/1zENImJWeFWsMz3tlKyY4rJdXyfKiDl92DG8mEja6BZorD4kZp71VPRS9XWyVAauk81hFmiIoeFqgbGOY78EwfYaHne7nHwOr3JUqZIj8r3iAV6VBgUS3d/DvaruJaPNxePuzYp2Ic+N6/6/k7TaGrIo+7oTWI6p8ngA=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1706109281; c=relaxed/simple;
	bh=z8c5svnXszdC1bd3gbB3D6/AbZAaE1S7/ldDetGc8Og=;
	h=From:To:Subject:Date:Message-ID:MIME-Version; b=RlRynhvHfd9D0q/tiSo9JrlW3u3F4guGFw6lYLcg8TW+ipXkchLKcF+62zdvHZECSEscxe73XYbmxxRrUMG1gQImclLiaA4nCy9o0Y/0D1Flwnc10sc27QOUNisdszjaUCPFv/drGJqJogdR9zOB86E60eKmgLAx0DlfOjhcalo=
ARC-Authentication-Results: i=1; server2.sourceware.org
References: <87fryomdy6.fsf@redhat.com>
User-agent: mu4e 1.10.8; emacs 30.0.50
From: Sam James <sam@gentoo.org>
To: Nick Clifton <nickc@redhat.com>
Cc: serge.guelton@telecom-bretagne.eu, binutils@sourceware.org
Subject: Re: RFC: Document unexpected behaviour of --fatal-warnings
Date: Wed, 24 Jan 2024 15:13:24 +0000
Organization: Gentoo
In-reply-to: <87fryomdy6.fsf@redhat.com>
Message-ID: <87frymkbl0.fsf@gentoo.org>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,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: <binutils.sourceware.org>


Nick Clifton <nickc@redhat.com> writes:

> Hi Guys,

Hi Nick,

>
>   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
>   precedent for options on the command line only affecting options that
>   come after it.  (I am thinking of the -L option here, although there
>   are probably several others).  So instead I am considering documenting
>   the current behaviour as expected.  (See the patch below).
>
>   What do people think ?

I'm OK with it either way. We're really used to this kind of linker
behaviour so it's not a problem to just document it. I've not hit
this as a problem at all.

Then if someone wants to improve it later on, so be it.

(We could maybe change the docs to say "may not affect" if we want
leeway to change it later.)

>
> Cheers
>   Nick
>

thanks,
sam