public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Thomas Schwinge <thomas@codesourcery.com>
To: Tom de Vries <tdevries@suse.de>, <binutils@sourceware.org>,
	<gcc@gcc.gnu.org>
Cc: Carlos O'Donell <carlos@redhat.com>
Subject: Forward GCC '-v' command-line option to binutils assembler, linker (was: [PING] nvptx: forward '-v' command-line option to assembler, linker)
Date: Wed, 21 Sep 2022 11:21:01 +0200	[thread overview]
Message-ID: <878rmd84n6.fsf@euler.schwinge.homeip.net> (raw)
In-Reply-To: <820c4820-aca2-29f2-8727-11aa3913ae68@suse.de>

Hi!

This is a question regarding command-line options for GCC vs. binutils
assembler, linker.  It came up during a patch review related to nvptx
assembler and linker, which live outside of binutils:
<https://github.com/MentorEmbedded/nvptx-tools>, and don't share the
standard binutils assembler, linker framework (because they're rather
different/simpler).  As such they also don't share the standard binutils
'as', 'ld' command-line interface, though it's of course helpful (to
users) to be compatible, as much as is feasible.

I had proposed for GCC "nvptx: forward '-v' command-line option to
assembler, linker" (see snippets quoted below), and during review we
found:

On 2022-09-05T17:02:26+0200, Tom de Vries via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> On 6/7/22 17:41, Thomas Schwinge wrote:
>> --- a/gcc/config/nvptx/nvptx.h
>> +++ b/gcc/config/nvptx/nvptx.h

>> +/* Assembler supports '-v' option; handle similar to
>> +   '../../gcc.cc:asm_options', 'HAVE_GNU_AS'.  */
>> +#define ASM_SPEC "%{v}"

> The ASM_SPEC part LGTM.

For reference, that GCC '-v' gets forwarded to binutils assembler is due
to 'gcc/gcc.cc:asm_options':

    1272        #if HAVE_GNU_AS
    1273        /* If GNU AS is used, then convert -w (no warnings), -I, and -v
    1274           to the assembler equivalents.  */
    1275        "%{v} %{w:-W} %{I*} "
    1276        #endif

That was added by Carlos some 15 years ago; Subversion r127275
(Git commit dc60b7754db561a029e42eeb297493726f8b8b33),
<https://inbox.sourceware.org/gcc-patches/20070801175134.GR18317@lios>
"Pass more options to the assembler".  ('-w', '-I' are not applicable to
nvptx 'as'.)

But that was for binutils assembler only, not for binutils linker, so
when for nvptx I additionally proposed:

>> +/* Linker supports '-v' option.  */
>> +#define LINK_SPEC "%{v}"

..., Tom rightfully asked:

> [...] I wonder, normally we don't pass -v to ld, and need -Wl,-v for
> that.

So, on my quest for making things uniform/simple, I now wonder: should we
also forward GCC '-v' to binutils linker, or is there a reason to not do
that?

(As far as I can tell, GCC 'collect2' is also already doing the right
thing regarding '-v'.)

I've manually run a few experiments with 'gcc -v -Wl,-v' (proposed to
then simplify to just 'gcc -v'), with both binutils 'ld.bfd', 'ld.gold',
and have not spotted any issues.  As 'ld.mold', 'ld.lld' also identify as
"compatible with GNU ld", I've likewise tested them, and again not
spotted any issues.  So I think we should be save to generally handle
'%{v}' linker spec for all 'HAVE_GNU_LD', or does anyone see any problem
with that?

(I've not yet thought about where in 'gcc/gcc.cc' to place '%{v}' linker
spec, guarded by '#if HAVE_GNU_LD'.)


> So, any particular reason why we would do things differently for
> nvptx?

Let's first work out why binutils assembler vs. linker are handled
differently.  ;-)


Grüße
 Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

       reply	other threads:[~2022-09-21  9:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <MentorEmbedded/nvptx-tools/pull/31@github.com>
     [not found] ` <MentorEmbedded/nvptx-tools/pull/31/c1094932979@github.com>
     [not found]   ` <874k185ak4.fsf@dem-tschwing-1.ger.mentorg.com>
     [not found]     ` <b2aa158a-28b7-04a9-f657-7b5e3d3604ed@codesourcery.com>
     [not found]       ` <871qw08orn.fsf@euler.schwinge.homeip.net>
     [not found]         ` <820c4820-aca2-29f2-8727-11aa3913ae68@suse.de>
2022-09-21  9:21           ` Thomas Schwinge [this message]
2022-09-22 11:32             ` Nick Clifton
2022-09-22 12:46               ` Richard Earnshaw

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878rmd84n6.fsf@euler.schwinge.homeip.net \
    --to=thomas@codesourcery.com \
    --cc=binutils@sourceware.org \
    --cc=carlos@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=tdevries@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).