* [RFC] Fix for PR driver/47785 [not found] <50C9F154.6090007@arm.com> @ 2013-01-22 16:00 ` Ramana Radhakrishnan 2013-01-23 15:36 ` Richard Biener 0 siblings, 1 reply; 5+ messages in thread From: Ramana Radhakrishnan @ 2013-01-22 16:00 UTC (permalink / raw) To: gcc-patches@gcc.gnu.org ; [-- Attachment #1: Type: text/plain, Size: 1004 bytes --] Hi, I ran into PR driver/47785 when doing some testing with an option passed to the testsuite and I chose to fix this by putting out COLLECT_AS_OPTIONS as though these are options for the driver by prepending them with a "'-Wa", and suffixing them with a "'" character and additionally providing spaces as duly required. I've chosen a simple implementation. Tested in the past with x86_64-linux-gnu and arm-none-eabi cross tests (with an additional -Wa option passed to the default flags in a site.exp) Thoughts ? Ok for trunk now or should I stage this for 4.9 ? regards, Ramana gcc/ <DATE> Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> PR driver/47785 * gcc.c (set_collect_as_options): New. (main): Call this. * lto-wrapper.c (run_gcc): Handle COLLECT_AS_OPTIONS. testsuite/ <DATE> Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> PR driver/47785 * gcc.dg/pr47785.c: New test. [-- Attachment #2: 2.txt --] [-- Type: text/plain, Size: 3591 bytes --] diff --git a/gcc/gcc.c b/gcc/gcc.c index 13e93e5..df18317 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -221,6 +221,7 @@ static const char *eval_spec_function (const char *, const char *); static const char *handle_spec_function (const char *); static char *save_string (const char *, int); static void set_collect_gcc_options (void); +static void set_collect_as_options (void); static int do_spec_1 (const char *, int, const char *); static int do_spec_2 (const char *); static void do_option_spec (const char *, const char *); @@ -4047,6 +4048,30 @@ process_command (unsigned int decoded_options_count, infiles[n_infiles].name = 0; } +static void +set_collect_as_options (void) +{ + int ix; + char *opt; + int first_time = TRUE; + /* Build COLLECT_AS_OPTIONS to have all of the options specified to + the compiler. */ + obstack_grow (&collect_obstack, "COLLECT_AS_OPTIONS=", + sizeof ("COLLECT_AS_OPTIONS=") - 1); + + FOR_EACH_VEC_ELT (assembler_options, ix, opt) + { + if (!first_time) + obstack_grow (&collect_obstack, " ", 1); + obstack_grow (&collect_obstack, "\'-Wa,", 5); + obstack_grow (&collect_obstack, opt, strlen (opt)); + obstack_grow (&collect_obstack, "\'", 1); + first_time = FALSE; + } + obstack_grow (&collect_obstack, "\0", 1); + xputenv (XOBFINISH (&collect_obstack, char *)); +} + /* Store switches not filtered out by %<S in spec in COLLECT_GCC_OPTIONS and place that in the environment. */ @@ -6579,6 +6604,8 @@ main (int argc, char **argv) obstack_grow (&collect_obstack, argv[0], strlen (argv[0]) + 1); xputenv (XOBFINISH (&collect_obstack, char *)); + set_collect_as_options (); + /* Set up to remember the pathname of the lto wrapper. */ if (have_c) diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c index 24de743..97786ce 100644 --- a/gcc/lto-wrapper.c +++ b/gcc/lto-wrapper.c @@ -445,6 +445,7 @@ run_gcc (unsigned argc, char *argv[]) char *list_option_full = NULL; const char *linker_output = NULL; const char *collect_gcc, *collect_gcc_options; + const char *collect_as_options; int parallel = 0; int jobserver = 0; bool no_partition = false; @@ -454,6 +455,7 @@ run_gcc (unsigned argc, char *argv[]) unsigned int decoded_options_count; struct obstack argv_obstack; int new_head_argc; + char * collect_gcc_as_options; /* Get the driver and options. */ collect_gcc = getenv ("COLLECT_GCC"); @@ -462,7 +464,14 @@ run_gcc (unsigned argc, char *argv[]) collect_gcc_options = getenv ("COLLECT_GCC_OPTIONS"); if (!collect_gcc_options) fatal ("environment variable COLLECT_GCC_OPTIONS must be set"); - get_options_from_collect_gcc_options (collect_gcc, collect_gcc_options, + + collect_as_options = getenv ("COLLECT_AS_OPTIONS"); + collect_gcc_as_options = (char *)xmalloc (strlen (collect_gcc_options) + + strlen (collect_as_options) + 1); + + strcpy (collect_gcc_as_options, collect_gcc_options); + strcat (collect_gcc_as_options, collect_as_options); + get_options_from_collect_gcc_options (collect_gcc, collect_gcc_as_options, CL_LANG_ALL, &decoded_options, &decoded_options_count); --- /dev/null 2012-12-06 14:23:58.292304805 +0000 +++ ./gcc/testsuite/gcc.dg/pr47785.c 2012-12-13 14:20:31.000000000 +0000 @@ -0,0 +1,11 @@ +/* { dg-options "-flto -Wa,--defsym=x=42" {target lto} } */ +extern int x; +extern void abort (void); +int +main (void) +{ + if ((int)&x != 42) + abort (); + + return 0; +} ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] Fix for PR driver/47785 2013-01-22 16:00 ` [RFC] Fix for PR driver/47785 Ramana Radhakrishnan @ 2013-01-23 15:36 ` Richard Biener 2013-01-23 15:50 ` Ramana Radhakrishnan 0 siblings, 1 reply; 5+ messages in thread From: Richard Biener @ 2013-01-23 15:36 UTC (permalink / raw) To: ramrad01; +Cc: gcc-patches@gcc.gnu.org , On Tue, Jan 22, 2013 at 5:00 PM, Ramana Radhakrishnan <ramrad01@arm.com> wrote: > Hi, > > I ran into PR driver/47785 when doing some testing with an option passed to > the testsuite and I chose to fix this by putting out COLLECT_AS_OPTIONS as > though these are options for the driver by prepending them with a "'-Wa", > and suffixing them with a "'" character and additionally providing spaces as > duly required. I've chosen a simple implementation. > > Tested in the past with x86_64-linux-gnu and arm-none-eabi cross tests (with > an additional -Wa option passed to the default flags in a site.exp) > > Thoughts ? > > Ok for trunk now or should I stage this for 4.9 ? I don't think this fix will work reliably - it's probably desirable anyway for other uses of -Wa,... but providing a symbol definition is something that needs to be understood by LTO at WPA time, otherwise we will get confusing / wrong symbol resolutions and eventually wrong code generated in the end. Thus with the patch you get some false sense of security I think (consider -fno-fat-lto-objects, you'd get x UNDEFed, and with -ffat-lto-objects you'd get a prevailing IRONLY def but the symbol wasn't in the LTO symbol table and we don't find a prevailing definition at WPA time ...) Thus, I think it at least has to wait ;) Richard. > regards, > Ramana > > > gcc/ > > <DATE> Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> > > PR driver/47785 > * gcc.c (set_collect_as_options): New. > (main): Call this. > * lto-wrapper.c (run_gcc): Handle COLLECT_AS_OPTIONS. > > > testsuite/ > > <DATE> Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> > > PR driver/47785 > * gcc.dg/pr47785.c: New test. > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] Fix for PR driver/47785 2013-01-23 15:36 ` Richard Biener @ 2013-01-23 15:50 ` Ramana Radhakrishnan 2013-01-23 15:53 ` Richard Biener 0 siblings, 1 reply; 5+ messages in thread From: Ramana Radhakrishnan @ 2013-01-23 15:50 UTC (permalink / raw) To: Richard Biener; +Cc: gcc-patches, gcc-patches On 01/23/13 15:36, Richard Biener wrote: > On Tue, Jan 22, 2013 at 5:00 PM, Ramana Radhakrishnan <ramrad01@arm.com> wrote: >> Hi, >> >> I ran into PR driver/47785 when doing some testing with an option passed to >> the testsuite and I chose to fix this by putting out COLLECT_AS_OPTIONS as >> though these are options for the driver by prepending them with a "'-Wa", >> and suffixing them with a "'" character and additionally providing spaces as >> duly required. I've chosen a simple implementation. >> >> Tested in the past with x86_64-linux-gnu and arm-none-eabi cross tests (with >> an additional -Wa option passed to the default flags in a site.exp) >> >> Thoughts ? >> >> Ok for trunk now or should I stage this for 4.9 ? > > I don't think this fix will work reliably - it's probably desirable > anyway for other uses > of -Wa,... but providing a symbol definition is something that needs > to be understood > by LTO at WPA time, otherwise we will get confusing / wrong symbol > resolutions and > eventually wrong code generated in the end. Thus with the patch you get some > false sense of security I think (consider -fno-fat-lto-objects, you'd > get x UNDEFed, > and with -ffat-lto-objects you'd get a prevailing IRONLY def but the > symbol wasn't > in the LTO symbol table and we don't find a prevailing definition at > WPA time ...) Can you define a symbol on the command line for the assembler ? I didn't know GAS or assemblers could do that and even if it did, I don't understand why ... The linker allows you a -Wl,--defsym=foo=<val> or whatever you want to do there, so even if the assembler were to have an undef reference to a symbol in an object file, it would get fixed up at link time by the linker. So if you are saying that we need to make LTO handle -Wl, --defsym=sym=<value> I'd envisage the need to handle potential confusion but even that's a separate patch and unrelated to this one ...... :) Intrigued :) cheers, Ramana ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] Fix for PR driver/47785 2013-01-23 15:50 ` Ramana Radhakrishnan @ 2013-01-23 15:53 ` Richard Biener 2013-01-23 15:53 ` Ramana Radhakrishnan 0 siblings, 1 reply; 5+ messages in thread From: Richard Biener @ 2013-01-23 15:53 UTC (permalink / raw) To: ramrad01; +Cc: gcc-patches On Wed, Jan 23, 2013 at 4:50 PM, Ramana Radhakrishnan <ramrad01@arm.com> wrote: > On 01/23/13 15:36, Richard Biener wrote: >> >> On Tue, Jan 22, 2013 at 5:00 PM, Ramana Radhakrishnan <ramrad01@arm.com> >> wrote: >>> >>> Hi, >>> >>> I ran into PR driver/47785 when doing some testing with an option passed >>> to >>> the testsuite and I chose to fix this by putting out COLLECT_AS_OPTIONS >>> as >>> though these are options for the driver by prepending them with a "'-Wa", >>> and suffixing them with a "'" character and additionally providing spaces >>> as >>> duly required. I've chosen a simple implementation. >>> >>> Tested in the past with x86_64-linux-gnu and arm-none-eabi cross tests >>> (with >>> an additional -Wa option passed to the default flags in a site.exp) >>> >>> Thoughts ? >>> >>> Ok for trunk now or should I stage this for 4.9 ? >> >> >> I don't think this fix will work reliably - it's probably desirable >> anyway for other uses >> of -Wa,... but providing a symbol definition is something that needs >> to be understood >> by LTO at WPA time, otherwise we will get confusing / wrong symbol >> resolutions and >> eventually wrong code generated in the end. Thus with the patch you get >> some >> false sense of security I think (consider -fno-fat-lto-objects, you'd >> get x UNDEFed, >> and with -ffat-lto-objects you'd get a prevailing IRONLY def but the >> symbol wasn't >> in the LTO symbol table and we don't find a prevailing definition at >> WPA time ...) > > > Can you define a symbol on the command line for the assembler ? I didn't > know GAS or assemblers could do that and even if it did, I don't understand > why ... > > The linker allows you a -Wl,--defsym=foo=<val> or whatever you want to do > there, so even if the assembler were to have an undef reference to a symbol > in an object file, it would get fixed up at link time by the linker. > > So if you are saying that we need to make LTO handle -Wl, > --defsym=sym=<value> I'd envisage the need to handle potential confusion but > even that's a separate patch and unrelated to this one ...... :) > > Intrigued :) Well, if you look at the testcase you added with your patch you see -Wa,--defsym=x=42, so the answer is yes. Richard. > cheers, > Ramana > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] Fix for PR driver/47785 2013-01-23 15:53 ` Richard Biener @ 2013-01-23 15:53 ` Ramana Radhakrishnan 0 siblings, 0 replies; 5+ messages in thread From: Ramana Radhakrishnan @ 2013-01-23 15:53 UTC (permalink / raw) To: Richard Biener; +Cc: gcc-patches > Well, if you look at the testcase you added with your patch you see > -Wa,--defsym=x=42, so the answer is yes. Bah I must be blind. Ramana > > Richard. > >> cheers, >> Ramana >> >> > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-01-23 15:53 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <50C9F154.6090007@arm.com>
2013-01-22 16:00 ` [RFC] Fix for PR driver/47785 Ramana Radhakrishnan
2013-01-23 15:36 ` Richard Biener
2013-01-23 15:50 ` Ramana Radhakrishnan
2013-01-23 15:53 ` Richard Biener
2013-01-23 15:53 ` Ramana Radhakrishnan
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).