On 01/23/13 15:36, Richard Biener wrote:
On Tue, Jan 22, 2013 at 5:00 PM, Ramana Radhakrishnan <ramra...@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
