From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) by sourceware.org (Postfix) with ESMTPS id 00EED3857820 for ; Fri, 20 May 2022 07:07:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 00EED3857820 Received: by mail-qv1-xf2e.google.com with SMTP id p3so6143140qvi.7 for ; Fri, 20 May 2022 00:07:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ahzCD0UKPgGhvRDmol78r8QbnNoP9UJ8QeThkDak7X4=; b=MLbLY79DwYwBmYjAettCQOFWq+foJhCpdbf3BCsHqFWKCT8gDWqr3PUM88XhwDCbgM kzfp2gf7SS5uLqcm74icwe0fyYMI8gKtmyO5JZLhaphPZxvzNwLn9gLNKj6YG5MVeKEV Q6+CPJjYyCZvNrOAsNWf0yEyJZ6p/GGmPhxYqGHFZqxXqluhq7wHPcVTPBA1QLyDZfGZ kPN+fMGZcl9gQc8LLLwxXKQn6zCsrdtxferjc6juPw8ItY+vBT4yMqIYvGmVDCP9nuwM EbmCTVSQO0h3+2mDEo4p9opaDyD3MzxOz9xqMkLlSyzsZNzkRdSOITKWj3txMgNqlnu2 XlLA== X-Gm-Message-State: AOAM5312VTxRi4Vy9o2yeCZp3OkXGTnXIbdVlydDBiuW/pvDPOe7IinA pkTb7giKZXuZKxglsauB5Gg3hmaYSm4V/cb4GF5eqw== X-Google-Smtp-Source: ABdhPJxuFltXKu3yRUVIcA5X7pooKsRk2DqG/EQ5rZMkioJaItUMRW5x6wh6TMrHNPiGFc3XJSFZ/kyWJYfjXZ6+kdY= X-Received: by 2002:a05:6214:1bcb:b0:45a:afd7:6f72 with SMTP id m11-20020a0562141bcb00b0045aafd76f72mr7071126qvc.20.1653030437409; Fri, 20 May 2022 00:07:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Cl=C3=A9ment_Chigot?= Date: Fri, 20 May 2022 09:07:06 +0200 Message-ID: Subject: Re: [PATCH] ld: harmonize the value of --enable-warn-execstack=no option To: Alan Modra Cc: Nick Clifton , binutils@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2022 07:07:19 -0000 Hi Alan On Fri, May 20, 2022 at 8:45 AM Alan Modra wrote: > > On Fri, May 20, 2022 at 03:24:23PM +0930, Alan Modra wrote: > > On Tue, May 17, 2022 at 02:51:40PM +0200, Cl=C3=A9ment Chigot via Binut= ils wrote: > > > This patch sets the configure value of warn-execstack to 2 when > > > disabled as expected by bfd. > > > > > > ld/ChangeLog: > > > > > > * configure.ac: Update ac_default_ld_warn_execstack value whe= n > > > --enable-warn-execstack=3Dno is given. > > > * configure: Regenerate > > > * testsuite/ld-elf/elf.exp: Add --warn-execstack to ensure > > > the warning is always shown. > > > > Thanks for the patch, but I'm suspicious of the testsuite change and I > > think we need a little more here. I agree a change is needed to make > > ld/bfd values consistent but I'm going to jump the other way, changing > > link_info.warn_execstack. Making it consistent that way is nicer in > > that the flag becomes an "extended" boolean, ie. 0 =3D> don't warn, > > 1 =3D> always warn, 2 or 3 =3D> conditional warning depending on > > link_info.execstack. > > > > Testing still in progress, I'll commit this shortly if I don't > > discover the need for a testsuite change. > > So my patch results in > aarch64_be-linux-gnu_ilp32 +FAIL: PR ld/29072 (warn about an executable = .note.GNU-stack) > aarch64-linux +FAIL: PR ld/29072 (warn about an executable .note.GNU-sta= ck) > armeb-linuxeabi +FAIL: PR ld/29072 (warn about an executable .note.GNU-s= tack) > arm-linuxeabi +FAIL: PR ld/29072 (warn about an executable .note.GNU-sta= ck) > arm-nacl +FAIL: PR ld/29072 (warn about an executable .note.GNU-stack) Thanks for handling this patch. However, the testsuite changes look mandatory to me. As of now, the results are different dependending on the configure options being passed. If the warnings are disabled, ld/29072 will always fail. If the warnings are forced, stack exec will fail too. I agree that forcing --warn-execstack might not be the right approach. Maybe disabling the problematic tests and creating new ones: tests that are run only when a given configure option is set, would be better. That way we can also check that the behavior of each configure choice is preserved. Cl=C3=A9ment