This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Fix for PR driver/47785
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
>
>