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