public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* Forward GCC '-v' command-line option to binutils assembler, linker (was: [PING] nvptx: forward '-v' command-line option to assembler, linker)
       [not found]         ` <820c4820-aca2-29f2-8727-11aa3913ae68@suse.de>
@ 2022-09-21  9:21           ` Thomas Schwinge
  2022-09-22 11:32             ` Nick Clifton
  0 siblings, 1 reply; 3+ messages in thread
From: Thomas Schwinge @ 2022-09-21  9:21 UTC (permalink / raw)
  To: Tom de Vries, binutils, gcc; +Cc: Carlos O'Donell

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

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

* Re: Forward GCC '-v' command-line option to binutils assembler, linker (was: [PING] nvptx: forward '-v' command-line option to assembler, linker)
  2022-09-21  9:21           ` Forward GCC '-v' command-line option to binutils assembler, linker (was: [PING] nvptx: forward '-v' command-line option to assembler, linker) Thomas Schwinge
@ 2022-09-22 11:32             ` Nick Clifton
  2022-09-22 12:46               ` Richard Earnshaw
  0 siblings, 1 reply; 3+ messages in thread
From: Nick Clifton @ 2022-09-22 11:32 UTC (permalink / raw)
  To: Thomas Schwinge, Tom de Vries, binutils, gcc

Hi Thomas,


>>> +/* 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?

Not really no.  Historically of course this has not been done, so changing
it now might surprise a few users.  But it should not be that big of an
issue.


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

Nope, none at all.

Harmonizing the effect of the -v option sounds like a good idea to me.

Cheers
   Nick


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

* Re: Forward GCC '-v' command-line option to binutils assembler, linker (was: [PING] nvptx: forward '-v' command-line option to assembler, linker)
  2022-09-22 11:32             ` Nick Clifton
@ 2022-09-22 12:46               ` Richard Earnshaw
  0 siblings, 0 replies; 3+ messages in thread
From: Richard Earnshaw @ 2022-09-22 12:46 UTC (permalink / raw)
  To: Nick Clifton, Thomas Schwinge, Tom de Vries, binutils, gcc



On 22/09/2022 12:32, Nick Clifton via Gcc wrote:
> Hi Thomas,
> 
> 
>>>> +/* 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?
> 
> Not really no.  Historically of course this has not been done, so changing
> it now might surprise a few users.  But it should not be that big of an
> issue.
> 
> 
>>> So, any particular reason why we would do things differently for
>>> nvptx?
> 
> Nope, none at all.
> 
> Harmonizing the effect of the -v option sounds like a good idea to me.
> 
> Cheers
>    Nick
> 

What's wrong with users passing -Wa,-v or -Wl,-v to pass the option 
through to the assembler and linker respectively?  The more flags like 
this we force pass to the additional tools the more likely we are to 
have problems when that tool is not from the GNU toolchain.

R.


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

end of thread, other threads:[~2022-09-22 12:47 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [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           ` Forward GCC '-v' command-line option to binutils assembler, linker (was: [PING] nvptx: forward '-v' command-line option to assembler, linker) Thomas Schwinge
2022-09-22 11:32             ` Nick Clifton
2022-09-22 12:46               ` Richard Earnshaw

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).