[llvm] r192775 - Revert r192758 (and r192759), "MC: Better handling of tricky symbol and section names"

[Hans Wennborg]

On Wed, Oct 16, 2013 at 6:18 PM, Hans Wennborg <hans at chromium.org> wrote:
> On Wed, Oct 16, 2013 at 4:44 PM, Hans Wennborg <hans at chromium.org> wrote:
>> On Wed, Oct 16, 2013 at 4:00 PM, Reid Kleckner <rnk at google.com> wrote:
>>> No idea.  .def is the COFF way of giving metadata about a symbol: function
>>> vs. data vs. section, and other things.  MC has an extra set of methods for
>>> emitting it.
>>
>> Right, so it doesn't seem like we can get away from using .def :(
>>
>> Looking at the gas source, I can see the difference in how parsing is
>> done for .set (done by s_set function) and .def (obj_coff_def). The
>> former uses read_symbol_name() which allows quotes, and the latter
>> uses get_symbol_end which doesn't.
>>
>> Quotes are also not allowed in labels, and that's documented so I
>> guess it's intentional.
>>
>> This means quoting these symbols doesn't work in practice.
>>
>> I'll try to fix our asm parser to allow for @'s in unquoted symbol
>> names in COFF instead, I think that's the way to go.
>
> That didn't work because of things like foo at IMGREL.
>
> I've gone back to the quoting approach and not emitting @feat.00 on
> non-win32, which means quoted symbols shouldn't be showing up on
> cygwin/mingw. Committed that in r192859.

I've reverted again in r192940. The clang-native-mingw32-win7 buildbot
was failing because the assembler was choking on these lines from the
asm of CrashRecoveryContext.cpp:

  movl  $"__ZL16ExceptionHandlerP19_EXCEPTION_POINTERS at 4", 4(%eax)
  calll "_AddVectoredExceptionHandler at 8"
  .def  "__ZL16ExceptionHandlerP19_EXCEPTION_POINTERS at 4";
  "__ZL16ExceptionHandlerP19_EXCEPTION_POINTERS at 4":
  calll "_RemoveVectoredExceptionHandler at 4"

I guess this is the __stdcall mangling, and we get that on mingw.

I'm not sure what would be the best way to fix this problem.



>>> On Wed, Oct 16, 2013 at 3:26 PM, Hans Wennborg <hans at chromium.org> wrote:
>>>>
>>>> On Wed, Oct 16, 2013 at 3:15 PM, Rafael Espíndola
>>>> <rafael.espindola at gmail.com> wrote:
>>>> >> with gas:
>>>> >> 00000000 b .bss
>>>> >> 00000000 d .data
>>>> >> 00000000 t .text
>>>> >> 00000000 T __Z1fv
>>>> >>
>>>> >> with clang:
>>>> >> 00000000 t .text
>>>> >> 00000001 a @feat.00
>>>> >> 00000000 T __Z1fv
>>>> >>
>>>> >> So if gas doesn't understand the @feat.00 thing, maybe we should only
>>>> >> do it when targeting win32 (which means using our own assembler,
>>>> >> right?), thereby avoiding this whole problem?
>>>> >
>>>> > What is wrong with using ".set"? That would work with gas too.
>>>>
>>>> The file looks like this:
>>>>
>>>> .def "@feat.00";
>>>> .scl 3;
>>>> .type 0;
>>>> .endef
>>>> "@feat.00" = 1
>>>> .def __Z1fv;
>>>> .scl 2;
>>>> .type 32;
>>>> .endef
>>>> .text
>>>> .globl __Z1fv
>>>> .align 16, 0x90
>>>> __Z1fv:
>>>> pushl %ebp
>>>> movl %esp, %ebp
>>>> movl $5, %eax
>>>> popl %ebp
>>>> ret
>>>>
>>>> I can fix the "@feat.00" = 1 by switching to .set, but it still
>>>> complains about .def on line 1. I don't even know what's going on up
>>>> there. Reid?